Yes you are missing something. Here is my reply on that email thread to Luis...

Take a step back... Let's use an old stand-by as an example:

class Order

Unknown macro: { ... @ManyToOne Customer customer; }

There are 2 ways to handle `Order#customer` being lazy behaviorally:

1. With Hibernate's default proxy approach, when the Order is loaded we take the `#customer` FK value and build a Customer proxy from it. That generated Customer proxy now controls its own initialization
2. With bytecode enhancement (assuming !NO_PROXY), when the Order is loaded we do not select any lazy state (`#customer` included). Later when the application accesses `#customer` we select the `#customer` FK and use that to build a Customer proxy. Essentially we have double laziness. And the creation of the proxy here is nothing more than a performance hit.

This is why NO_PROXY came about initially. Like so many things in Hibernate, bytecode enhancement was initially "bolted on" rather than deeply integrated. We started down the path of deeper integration in this new bytecode enhancement and in many ways we ought to look at this an an opportunity to "fix things". This is why I suggested that we ought to consider handling this automatically. There is never a time that generating a proxy for a lazy to-one attribute is going to make sense when the container (Order) is bytecode enhanced for laziness.

---

This brings up another consideration. IIUC ATM we issue 2 different selects here in the "bytecode enhanced lazy to-one" approach:
Loads the FK value (select o.customer_id from orders o where o.id = ?)
Loads the related state (select ... from customers c where c.id = ?)
We really ought to investigate combining those into one with a join.

Put as simply as I can... the proxy approach is Class based whereas the enhancement approach is attribute based. In the bytecode approach we handle the laziness of attributes at the attribute level, never at the class level.