Thanks for the details. I created to address the mass indexing use case. It is not always appropriate in case of mapping changes, but it can help in some cases nonetheless.

It's optimistically scheduled for the beta phase of Hibernate Search 6; I'd really like this feature to be in 6.0.0.Final. We'll see what time permits

Yes - you understood correctly. Sorry, I was not that precise.

I already stumbled upon some days ago because I was looking for a "hot update" solution with HSearch and ES.

My Idea was to copy the current index and redirect the queries to the copied one while I make a full rebuild with the MassIndexer to the original index.

I would only do that when I know, that the code base and HSearch/Index configuration were not changed. I need to rebuild my index from time to time because unfortunately there is sometimes data inserted in my database without using the Hibernate ORM layer.

Altering the path in the search request would me allow to do this trick without the need of a fully automated deeper integration in HSearch.

Thank you for your feedback. So if I understood correctly you would need to:

1. Add/alter query parameter in the HTTP request (in your case, the search_type parameter).
2. Alter the path of the HTTP request (in your case, the targeted indices).

Two other use cases we had in mind were:

3. Altering the JSON of the request, for example to add suggesters.
4. Parsing parts of the JSON response, for example to retrieve the value of the suggestions. That would allow to take advantage of features that are not (yet) supported by Hibernate Search, without having to build the whole request yourself.

I'm not so sure about the second one (altering the path): I suspect a deeper integration would be better. For example we could make Hibernate Search aware of the aliases, maybe even manage them: that could be useful for hot updates, see HSEARCH-2861. But that's a much larger problem, so maybe just providing some hook to alter the path would be enough as a first step.

Just so we can understand the problem better: why exactly do you need the search query to target aliases or special indices? What do you use aliases for?
Note that you could get a behavior roughly equivalent to "_all" by targeting Object.class instead of MyEntity.class when creating your query.