Steve Ebersole Thanks for the hasProxy that lead me here. It got me wondering whether...

1. The Session.internalLoad should be also given the unwrapProxy for better decision making because now EntityType.resolveIdentifier bundles this with nullability. To make matters more obfuscated there also the same instrumentation check as you posted here which is also bundled up into the nullability information. This feels to me like a bottle neck because in the SessionImpl.internalLoad that comes next unravels LoadType from eagerness and nullability, but there is also allowProxyCreation that could carry the unwrapProxy information further. The instrumentation information could be left out because the method you described handles this already.
2. The hasProxy you mentioned should not include isInstrumented because this information is available in identically named method already. Via this method the FetchStrategyHelper.determineFetchStyleByMetadata and others can still determine whether to proceed or not.

This way the DefaultLoadEventListener.proxyOrLoad would have better means to make decisions whether to load or not in case I want both proxies and lazy instrumentation at the same time. Now the behavior expects that either there is a proxy or lazy instrumentation but one can not have both. I think this should be allowed at least in 5.x because currently the lazy instrumentation is quite useless to me at least because it effectively makes getReference() behave differently than in 4.x.

PS. The AbstractEntityPersister and AbstractEntityTuplizer should have a same base class for (entity) metamodel related issues. Both of them have this hasProxy method but the latter one is missing isInstrumented for no apparent reason. I got even an NPE since the hasProxy wasn't even used when determining whether or not to initialize ProxyFactory.