I just had a look, and started working on this, but I think the scope of this problem is larger than anticipated.

We don't use proxies when bytecode enhancement is enabled, and one of the reasons (I think) is that proxies cannot handle some use cases that bytecode enhancement does handle. In particular, public entity fields generally will not work with proxies (see HHH-11550 Open ), so a common solution is to not use proxies at all and rely on bytecode enhancement for lazy loading instead.

If we start using proxies when bytecode enhancement is enabled, we run the risk of breaking several existing applications out there. Even if we only do it in some very specific cases. So that's not something we can do, at least not by default. We might be able to add a configuration option to opt-in, I guess.

Ideally, what we should do when populating a lazy *ToOne property is to instantiate the (bytecode-enhanced) entity class, and populate only its ID, leaving the other properties unfetched so that they will be initialized lazily. This would apply to both the properties marked as lazy in the mapping, as well as to the properties marked as eager in the mapping.

However, it's not trivial for multiple reasons:

1. org.hibernate.bytecode.enhance.spi.interceptor.LazyAttributeLoadingInterceptor explicitly only handles lazy loading for properties marked as Lazy in the mapping, so in the solution I proposed above, only those properties would actually be initialized lazily; the eager properties would be considered as already initialized and would never get initialized. We would have to change that in order to support lazy initialization for all properties, and I'm not sure of the performance impact of such a change.
2. Currently, there isn't any way to instantiate an entity "without loading", while still considering it bound to the database. I'm not sure Object instantiate(Serializable id, SharedSessionContractImplementor session) is a good fit because it has no notion of a lock mode, among others. The rest of the code instantiating an entity also deals with database queries, so as to populate all the eager properties (and probably create the database locks if necessary. Thus we would probably have to change the EntityPersister interface and the EntityLoader interface to add new methods, something like Object instantiateWithoutLoad(Serializable id, Object optionalObject, LockOptions lockOptions, SharedSessionContractImplementor session)
3. For consistency, when Session.get() is called for an entity that was previously instantiated "without loading", we should probably initialize all the eager properties.

So... for now I'm putting this on hold, we can discuss this next Monday.

For future reference: I tried to enable proxies by default even when bytecode enhancement is enabled, see my branch. But as I said above, and as demonstrated by the failing test, this would break some existing applications, so it's not a good idea.