I just read the JPA 2.1 specification.

Entity graphs are query hints. Query hints can be passed to any CriteriaQuery. There is not a single line that says that they cannot be applied to CriteriaQuery using multiselect.
So my conclusion is that multiselect CriteriaQuery should also follow the fetch graphs, aka the relationship laziness.

Your examples do not include anything about Entity Graphs, so I don't understand why did you mention those when your issue is about projecting entities with multiselect. Entity Graphs are for entity queries, not DTO projections.

The relation is optional and lazy.

You never provided the entities. The entities which I took from this GitHub repository were using the default EAGER fetching anyway.

At best, I expect Hibernate to not join at all on the foreign table.

As long as you are explicitly selecting an association and was to project it, how can the database do that without a JOIN?

At worst, I expect Hibernate to perform an outer join.

Implicit joins, like the one you did in the select clause, are always INNER JOINs. This is also specified by the Hibernate documentation.

Projections with lazy loaded entities allow to build views quickly.

And DTO projections work even better than that because you can select just as much info as you need.

I think this ticket should be at least reopened as an improvement.

I'm not sure which part would require an improvement because there many assumptions that turned out to be wrong, and those cannot be addressed. The JOIN, which is exactly what you complained about, is necessary because you added it explicitly to the SELECT clause.

Now, constructor results work for DTO projections, they are meant for entities, in which case only the ID will be mapped. You can try with Tuple and it should work. If it does not, then you should open an issue for that.