It was recently suggested that we backport the upgrade to Hibernate Search 6.2 from Quarkus 3.3 to Quarkus 3.2.
 
This would involve backporting these two PRs:

• https://github.com/quarkusio/quarkus/pull/34602
• https://github.com/quarkusio/quarkus/pull/34251

I originally did not plan to do that because I knew Search 6.2 wouldn't be ready for Quarkus 3.2, and I didn't realize backporting the upgrade was an option, but I must admit there are benefits:

• Hibernate Search 6.2 of course packs quite a few interesting features (highlighing, DTO projections, ...), though that's probably not a criteria in this case.
• Hibernate Search 6.1 is only officially compatible with Elasticsearch up to 7.x, and Elasticsearch 7.x is going to be EOL'd soon (happens in August 2023 or soon after). Hibernate Search 6.2 is officially compatible with Elasticsearch up to 8.x.
• EAP 8 will use Hibernate Search 6.2, so in the interest of aligning dependencies, using Hibernate Search 6.2 in RHBQ 3.2 would be a good thing.

As to downsides:

• Of course there is the risk of introducing regressions, this being about one year worth of changes. Though the more risky change areas in Search 6.2 are around classpath scanning, which is not a concern for Quarkus as it's disabled (we do it at build time in Quarkus itself).
• The vast majority of Hibernate Search 6.2 is backwards-compatible with 6.1, but there are a few backward-incompatible changes. Though they either affect a small portion of users (geo-spatial indexing) or preview extensions (outbox-polling, not included in product). See https://github.com/quarkusio/quarkus/wiki/Migration-Guide-3.3#hibernate-search