Johannes Geiger, I'm actually considering a slightly different approach and would like your input.

If we change what org.hibernate.envers.revision_field_name influences, this introduces a backward compatibility issue. We either have to allow a secondary configuration property that allows the behavior you are asking for (disabled by default) or allows legacy implementations to disable the behavior to remain consistent with their current schema (enabled by default).

One option is we introduce a new configuration property to allow you to also influence the naming in the REVINFO table so that you can have column name consistency. But I feel doing that will only lead to situations where users will want additional properties to customize the other attributes of the revision entity such as the timestamp column name, the name of the table, plus the modified entity names feature if they're using that. It's at this point I take a step back and question why introduce all these configuration properties when users can already customize all those features to their liking by merely introducing their own revision entity implementation to the mix as I suggested previously.

I feel the the documentation is already fairly clear that the org.hibernate.envers.revision_field_name targets the audit entity and not the revision entity. But what we could do for clarify sake then is to add a note so that if users wish for consistency between the revision entity and their audit entity tables, they should consider a custom revision entity implementation and override the column names as desired.

Thoughts?