I guess what makes this situation particular for us is that we are using Hibernate Search on Elasticsearch specifically just as a fast linguistic search database for values which are actually stored elsewhere (in a regular relational database)

Yep, that makes a lot of sense

since we have a clustered application and dynamically add things to the index, restarting to solve the issue is tricky to do with auto-index creation enabled, since by the time one app starts up and initializes Hibernate Search, another still-running app instance may have already auto-created the “bad” index

Unless I'm mistaken, this means the solution of re-creating the index automatically on write would not solve your problem: old-gen applications could re-create the index automatically with the "bad" schema. In fact you would be in an even worse situation: right now you're only in trouble when an old-gen application restarts; with the change, you're in trouble as soon as an old-gen application writes anything to Elasticsearch...

Wouldn't it be more appropriate to allow you to request Hibernate Search to re-create the index explicitly? That way you could do it at the time that makes most sense (only you know when that is) and in the latest version of the application (same, only you know about application versions, not Hibernate Search).
If you're using the MassIndexer, that feature could be built into it: call .dropAndCreateIndexes() instead of .purge() before starting the mass indexer, and it will drop the indexes

However, whatever the solution, there will always be a short time during which indexes will not exist and thus read/writes will all fail. An alternative would be HSEARCH-3499 Open , but it will be significantly more complex to implement (and test).