Tilman Müller, there is no need for a reproducer; I actually believe i see how this happens and why.

For the use case you described, the BaseEnversCollectionEventListener#showGenerateRevision method always returns true because the owner of the collection is audited and the collection is neither an inverse collection or one-to-many. What this means is the collection is owned by the owning entity, in your case Research.

So why do we generate a revision for Research? It's actually quite simple.

Lets assume for a moment you create your Research entity with one element in the collection during revision 1. At some future point you modify the collection in some way, lets call this revision 2. If this configuration property actually played a role, what you'd actually see in the audit table would be one row for Research with revision 1 and two rows in the collection audit table with revisions 1 and 2.

The question is how would you ever be able to query revision 2? Short answer, you wouldn't. The collection is of enums, a basic type and since it isn't an entity, you aren't able to use the query api to ever fetch such a revision.

I'm open to suggestions here but I think what I changed for HHH-10201 Closed makes logical sense from a query perspective. Its just a special use case for element-collections where the org.hibernate.envers.revision_on_collection_change is ignored because that setting isn't technically applicable for element-collections. Perhaps better explanation in the documentation and the javadocs is warranted here for clarity?