Another issue with this is that we're not currently using the entity property path in Elasticsearch, but rather the field path (which may be different when using things like @IndexedEmbedded.prefix, @Field.name, or simply custom field bridges). So adding support for fields would mean removing support for features such as @IndexedEmbedded.prefix, for instance.

Also, we'd probably have an issue with such a mapping:

@Field(name = "custom1", bridge = @Bridge(impl = SomeImpl1.class))
@Field(name = "custom2", bridge = @Bridge(impl = SomeImpl2.class))
private Foo bar;

What would be the name of the property in the Elasticsearch mapping? We don't have a clear candidate for that, since the default name is not attributed to any field, and we wouldn't know which ES datatype to use for this default name anyway.

Side-note: fields are being used right now in a very specific context: faceting. See https://github.com/hibernate/hibernate-search/pull/1217 ( HSEARCH-2451 Pull Request Sent ).

Bottom line: in my opinion, there's more to this ticket than just slightly tweaking the way we map Hibernate Search fields to Elasticsearch properties/fields. It's a more of a deep change in our internal representation of a document and field tree.

Anyway... To me, it's Hibernate Search 6.0 material, since adding such feature would probably require definitely removing support for some features in Elasticsearch (@IndexedEmbedded.prefix in particular).
Sanne Grinovero Ok to move this to 6.0?