But he told me, this would come with the problem of relying on Lucene playing nice with the classes.

Not sure what "playing nice with the classes" is supposed to mean.

Allowing the purging of Ids would indeed be nice. That would also require a new WorkType.

Not sure whether a new work type would be required, but for sure changes to the existing deletion work type. But that is really internal stuff.

As of the deleteByQuery(...) with a Lucene Query as the argument: I don't know whether we can reliably convert from Lucene Queries to a serialized version and back and if it works,

Maybe, maybe not. I think we discussed the need for "serializing" Lucene queries in other contexts as well. Since there is an approach which does not use query serialization (query by projection and purge), we don't have to solve this problem right now. Once we have a proper solution it would be a matter of changing some internal parts.

That's the general idea behind my "CustomBehaviour" stuff. Instead of not telling the users we could face problems we make sure they know that this is an expert feature which requires them to think before they do stuff.

I find it just confusing. I don't expect the user to know/learn about special deletion queries which really map to Lucene queries in the end.

In fact, we could allow both methods in the FullTextSession. One with the projection + purge (short: PP) approach and one with the custom behaviour.

As said, I go for the first option for now and see what happens.