Would that still not leave the old index around. After all this index is not backed anymore by an entity. How would the mass indexer delete it?

I was assuming the problem is with indexes which are still managed, but contain stale entities - on top of valid indexed entities. So in this case the goal would not be to delete the whole index but to purge the individual entries which don't match anymore.

If I misunderstood and the goal is to completely delete an index which is no longer used, then we wouldn't even have an IndexManager for it so adding such a purge(indexName) method wouldn't be of use. In this case I don't see why the user can't just rm -R the index from filesystem. Easily scripted, and not very different than what an Hibernate Search helper would do.

I suspect Marc would essentially need the purgeAll(Class) method to be valid even if the type passed as argument is not currently indexed. I'm afraid that's not possible to do automatically, as without an @Indexed annotation we can't guess the valid index name. It's solvable with a custom query though, which the user would need to use as an ad-hoc script, as a one-off alternative to the MassIndexer; I'm assuming this could be worth the user hassle of the low-level API for very large indexes, especially as your only alternative would be to open the index with a self-written tool making direct usage of the IndexWriter API, bypassing all of the Search engine.