Another way to manage this situation is the following: if I'm right there are no FK constraints between audit tables, apart from the FKs towards the central revision table: so I think it would be reasonable to remove some audit history from an entity leaving the historical references to it and, when one query for historical data that references the erased data, the Envers API might treat such broken relations as "lost data", returning null and empty collections or some other sentinel object. After all, it is the developer's responsibility to manage such events and give user with the appropriate information.

I think its also important to consider the fact there are audit queries that use inner joins for optimization reasons. Your proposal would force some of those queries to use outer-joins and I'm not convinced that is the right avenue here. For some of our users, this could be a massive performance impact for them given the size and volume of their audit tables and schemas.

I can see the value in being able to support removal of audited data; i'm just not sure on its implementation.