As mentioned on the PR:

Actually, we'll probably switch directions on this one:

We discussed it extensively on IRC this morning. As mentioned on http://docs.jboss.org/hibernate/orm/4.2/devguide/en-US/html/ch12.html, the org.hibernate.Criteria API is legacy and should be considered mostly deprecated. For the most part, we had decided not to accept new features for it. Instead, we're starting to focus on the JPA Criteria API which is much more powerful and concise. Yes, I did go against that and merged #554, but that was a really narrowly scoped issue that won't require much support. However, we feel that this new feature is too far-reaching and may require additional work/support in the future (ensuring other areas are "alias-aware", etc.).

Further, your specific use case (and others) can already be accomplished by JPA Criteria. For example:

09:55:06 AM) sebersole: so in your example...
(09:55:48 AM) sebersole: you'd have references to "c" and "e" which would be some type of javax.persistence.criteria.From
(09:55:56 AM) sebersole: a Root, or Join, or Fetch
(09:56:09 AM) sebersole: and you'd get a path like:
(09:56:30 AM) sebersole: Root<Person> personRoot = ...;
(09:57:31 AM) sebersole: Path<Person,String> personCodePath = personRoot.get( Person_.code );
(09:57:44 AM) sebersole: / same for "e"
(09:57:53 AM) sebersole: and then...
(09:59:02 AM) sebersole: criteria.where( builder.eq( builder.lower( personCodePath ), otherCodePath ) )

If other use cases are found to be missing, we'd rather focus on creating extensions there, rather than in the legacy Criteria. Sorry for stringing you along. Let me know if you have any comments.