I spoke with Christian Beikov about this on HipChat.

Sure, you can use an identification_variable as an argument. E.g. select new DTO( a ) from Animal a. That's really all JPA says on the matter. And in fact Hibernate supports that. That is a perfectly valid query that Hibernate will gladly parse and execute for you.

What you are asking for as a specific interpretation of what that means, which I am sorry but JPA does not say specifically. It does not say that the constructor should take the thing referenced by the identification_variable versus the id of the thing referenced by the identification_variable versus anything else. The closest it comes is in section 4.8.2 Constructor Expressions in the SELECT Clause, where it says:

If a single_valued_path_expression or identification_variable that is an argument to the constructor references an entity, the resulting entity instance referenced by that single_valued_path_expression or identification_variable will be in the managed state.

I can certainly see the argument that this should imply that the constructor should accept the entity here. However, as far as specs go, implying something and requiring it are 2 VASTLY different things.

The interpretation where we expect the constructor to accept the entity rather than the id goes against some basic and deep assumptions of Hibernate query parsing internals which pre-date JPA. I do not plan on changing this against those internals short of the JPA spec getting a revision that explicitly mandates expectations on the ctor args.

Now with 6.0 we are re-writing query parsing and execution from scratch. I will reconsider this wrt the work for 6.0 which is based on a new "semantic interpretation" model (SQM). SQM defines much different (better) support for "dynamic instantiation". For example, you can now define multiple constructor expressions in a query, you can nest constructor expressions, etc. How the SQM is interpreted into SQL is still ongoing. The SQM has the information needed to make this alternate decision. Like I said, I am open to reconsidering this for 6.x. But this will certainly not change for any releases prior to 6