While I may be splitting semantics here, I just want to be clear that the data previously generated prior to the fix in HHH-11582 Closed is not incompatible.

The problem boils down to the fact that prior to HHH-11582 Closed , queries that used the hasChanged() predicate would return incorrect results if you persisted and then updated the same entity within the same transaction. This scenario is very dependent on your persistence code in your application so its hard to really gauge the overall impact to users this had. The data after the fix obviously makes queries that utilize hasChanged() work across all persistence operations regardless if they occur within the same or across multiple transactions.

That said, a general rule here is that when REVTYPE = 0 and the column is not null or collection is not empty, the associated _MOD field should be TRUE / 1. It should be trivial to write a small migration application that looks at revisions of audited entities, compares the state between 2 revisions and uses JDBC to update the appropriate fields should you desire consistency with rows generated prior to HHH-11582 Closed . Honestly, it's things like this which I'd like to spend time doing some R&D on to try and devise a way that perhaps Envers could do some of this for users, but often times there are so many variables at play that may not always be possible.

The only use case that the above wouldn't be able to differentiate would be empty collections versus null collections; however from a real technical perspective, would could argue that the collection wasn't modified even if it was initialized as not-null. So leaving those column values as FALSE / 0 for rows prior to HHH-11582 Closed versus them being TRUE / 1 afterward really don't impact the end result imo.