In cloud-tm the proposal is that options like @Basic(fetch=LAZY) should be dynamic, so that a pluggable optimizer strategy could change them at runtime from measured behaviour.

OK, That could even be implemented in ORM proper then. But I ahve to admit, I'd like to see some real-life-ish scenarios where that would be beneficial.

Similarly, the cost of looking up entries which are actually null is high: in Infinispan for example the null value is not cacheable, which means you'll always trigger a remote load and/or a CacheStore hit to find the missing entry. Avoiding the loading attempt could have some benefits on this - however I'd agree that it should be preferrable to fix this in Infinispan's design.

So you mean a look up by id where the entity has been deleted already, correct? I am not sure how lazy properties help here.

I can see how it could help if the backend store each property in an individual key like one of the cloud-tm approach but OGM does not do that and I don't think there is much value in this since we use AtomicMap and hopefully, Infinispan will know how to retrieve partial AtomicMap at some point in the future.