Some quotes from the envers webpage:

The Envers module aims to enable easy auditing/versioning of persistent classes.

So, the target is to make it easy to the user.

For each audited entity, a table will be created, which will hold the history of changes made to the entity.

My entity is audited, a table is created, but it does not hold the history of changes made to it.

Basically, one transaction is one revision (unless the transaction didn’t modify any audited entities)

I modified the audited entity, but no new revision is created.

[...] auditing of all mappings defined by the JPA specification
[...] querying historical data

It should work with the JPA specifications and I should be able to query for historical data, which I am not able to, since there is no historical data.

And regarding your question

Look, have you ever stopped to think about how support for this would have to be implemented?

I already wrote

For example when executeUpdate() is called on CriteriaDelete, Envers could simply extract the conditions and then select the matching ids and do the auditing stuff. Same for CriteriaUpdate. There is no need to have the users do that stuff!

If Hibernate is not offering some injection point to executeUpdate, that may be added too or one can use e.g. AspectJ for that.

To conclude: Yes - in my opinion - this is a big bug, since Envers is not holding what it is promising.