save() happens to be different if the id generation uses column id. In this case, ORM must persist the entity right away because save() returns the identifier. In this case, the entity is stored and the index operation is in the queue. Clearing the indexing queue in this case will make the index inconsistent with the database (unless the DB is rolled backed).

This is quite common I think, also because when such an entity is persisted which needs a generated id, the whole persistence context is flushed (not just that entity), which means we get all persist events collected in Search's Queue.

So in some ways, clear() is fine by not clearing the queue, or maybe it should force a queue flush before actually clearing.

Good point. But are we going to argue that Session.clear() is inconsistent? It probably is, but seems to be useful. Trying to think about when it's useful, you're probably right that people want to Session.flush() first, they can do the same with the indexing backend which makes this feature indeed redundant.