We need entity type expressions in DQL that allow to discriminate types in the query. In SQL this would mostly just map down to a discriminator column/value comparison. Entity type expressions are covered in section 22.214.171.124 of the spec. The proposed syntax there sounds good to me, unless someone has a better idea.
Some implementation ideas: In the case of "binding" the types (Nr. 2/3) this is non-trivial since we can not just bind class names as strings since we need to convert the class names to their discriminator type. Instead, we could have special handling for parameters of type "ClassMetadata" or "ReflectionClass". That means in case Nr. 2, :empType1 and :empType2 would be bound as such instances, not as strings. That way we can clearly distinguish them and see that this means a "type" and not just a normal "string" (since PHP does not have any type literals, i.e. Foo.class, unfortunately).
Example Nr. 3 is not really necessary as a start and I think depends on another ticket that is about allowing binding arrays/collections to single placeholders in the query, so this is partly out of scope of this ticket alone.
Class names themselves in a DQL query could be converted to their discriminator values in conditional expressions (Nr. 1 and 4, anywhere else needed?). TYPE() itself does probably not make sense everywhere also. Example Nr. 4 mentions TYPE() in the SELECT part, but this has to be seen in the context that this would return Class<?> instances in Java. The equivalent would be ReflectionClass or ClassMetadata instances. This might be non-trivial to do since it might affect hydration. In the conditional part (WHERE), TYPE() probably converts simply to the name of the discriminator column. If we do the same in the SELECT part it would be easier but this would then return "discrimnator values", and not some sort of class instances, which may not be of that much use.
First step for implementation: Suggestion for updated EBNF.
Second step for implementation: Adjusting the Parser to recognize the new language construct (probably at least 1 new AST node needed).
Third step for implementation: Adjusting the standard SQLWalker to produce the appropriate SQL for the new language construct.