When other tools, such as serialization helpers, deserialize a detached enhanced entity, or otherwise materialise a new instance of the entity by calling the constructor and then setting field l(property) values via reflection, they might fail to set the dirty status correctly for fields which have been set at a value which matches the default value of the Java language.
Apparently this is a smart optimisation that some such tools perform (like Apache Jackson), and leads to bypassing the dirty status stracking implemented by SelfDirtinessTracker.
To make this foolproof, an idea which was discussed at last team meeting was to also store a state of "trusted" in the entity: this state would not be set by merely invoking the constructor (it would not be the default), but Hibernate ORM could set a managed entity to "trusted" when it's materializing the instance itself.
On merge (and similar) operations, a detached entity which is being reattached would be checked for this flag; when not set, the dirty-ness processing of the entity would fall back to use the safer, not optimised strategy.
As a side effect, it seems there's the possibility to apply some optimisations in the state handling of the SelfDirtinessTracker to reduce unnecessary allocations of tracking arrays.