This follows up on HSEARCH-2419 Closed and HSEARCH-2508: HSEARCH-2419 Closed had the exact same purpose, has been fixed, but the fix had to be reverted in HSEARCH-2419 Closed due to regressions that are not acceptable in a minor.

The org.hibernate.search.bridge.impl.BridgeFactory.getContainerType(XMember, ReflectionManager) method, responsible for determining the container type which will be used among others in org.hibernate.search.bridge.impl.BridgeFactory.getFieldBridgeFromBridgeProvider(BridgeProvider, ExtendedBridgeProviderContext, ContainerType), relies on an @IndexedEmbedded annotation being present on the property.
This means in particular that array/iterable/map field bridges will only be affected to a property if this property carries both a @Field and a @IndexedEmbedded annotation.
But when you want to index an array of strings, for instance, putting an @IndexedEmbedded annotation on the property makes no sense, because the purpose of this annotation is to "allow[...] queries involving associated objects properties". Also, the documentation exclusively refers to this annotation in the context of {{@Embeddable}}s or entities, with no word about array bridges.
Furthermore, such practice causes trouble when trying to create an Elasticsearch mapping, as it results in the Elasticsearch property for the embedded and the Elasticsearch property for the Field having the same name.

We should agree on a way to map "composite" properties more cleanly. There are two approaches:

• "unwrap" properties by default (like we did in HSEARCH-2419 Closed , but that was reverted), and require users to put specific annotations/annotation attributes to disable unwrapping (this wasn't implemented when fixing HSEARCH-2419 Closed )
• or do not unwrap properties by default and require users to put specific annotations/annotation attributes to enable unwrapping (like we did in https://github.com/hibernate/hibernate-search/pull/1253, but the PR was rejected)