I wonder whether we should do this in 5.8 or 6... Clearly it's a breaking change, but Elasticsearch integration being experimental, we could do it. And it would allow to prepare users for changes coming in 6.
On the other hand, the public material (presentations, etc.) out there would instantly become obsolete, referring to nonexistent configuration properties...

Currently:

1. Some options must be prefixed with either hibernate.search.default.elasticsearch or hibernate.search.indexname.elasticsearch (refreshAfterWrite, schema management, wait timeout, ...)
2. Some options must be prefixed with hibernate.search.default.elasticsearch, but we envisioned to make them configurable per index when we allow connecting to multiple elasticsearch clusters (these are the client options)
3. Some options must be prefixed with hibernate.search.elasticsearch (query options + analysis definition provider)

Category 1

Category 1 seems fine.

Category 2

Category 2 is problematic in my opinion, because when we allow connecting to multiple elasticsearch clusters we'll probably want to allow multiple index managers to use the same client. Which means in particular that we won't be able to configure those options using a hibernate.search.indexname.elasticsearch prefix: we'll probably want something like this instead:

hibernate.search.backend.backendname.type elasticsearch
hibernate.search.backend.backendname.host http://localhost:9200
hibernate.search.backend.backendname.username foo
hibernate.search.backend.backendname.password bar
hibernate.search.backend.backendname.discovery.enabled true
hibernate.search.backend.backendname.discovery.refresh_interval 10

hibernate.search.myIndex.backend backendname

We could optionally use a ".elasticsearch" in the prefix for backend properties, but that seems unnecessary.

But here's the catch: this is totally incompatible with the current prefixes used in properties.
If, on the other hand, we switched to something like "hibernate.search.backend.elasticsearch." as a prefix for category 2 properties, migration would be way easier once we allow multiple backends: once we introduce proper backend concepts into Hibernate Search, users would only have to add a "type" property to their backend and replace the "type" property of their indexes with a "backend" property". For instance this:

hibernate.search.backend.elasticsearch.host http://localhost:9200
hibernate.search.backend.elasticsearch.username foo
hibernate.search.backend.elasticsearch.password bar
hibernate.search.backend.elasticsearch.discovery.enabled true
hibernate.search.backend.elasticsearch.discovery.refresh_interval 10

hibernate.search.myIndex.type elasticsearch

Would become that:

hibernate.search.backend.elasticsearch.type elasticsearch
hibernate.search.backend.elasticsearch.host http://localhost:9200
hibernate.search.backend.elasticsearch.username foo
hibernate.search.backend.elasticsearch.password bar
hibernate.search.backend.elasticsearch.discovery.enabled true
hibernate.search.backend.elasticsearch.discovery.refresh_interval 10

hibernate.search.myIndex.backend elasticsearch

Category 3

Finally, category 3 raises another issue: they are very few, and inconsistent with other properties. Moreover, as long as we don't allow queries to span multiple Elasticsearch clusters (and I don't think we should, ever), these properties could be made backend-specific (category 2). But that would require changing their prefix...