I think we should be able to add support for polymorphism in @IndexedEmbedded, e.g. when encountering @IndexedEmbedded private A a;, consider the mapping of not only A, but also its subclasses B, C, ... That would only be possible for entity types, though, where we know all the subtypes upfront.

That being said, there would be some challenges:

1. This feature would imply defining fields from different classes (B}, C, ...) in the exact same place in the index schema.
   • We would have to allow some conflicts: fields contributed from different entity types with the same name, but the exact same options, or "compatible" options (if one contribution declares the storage type as "default", then it's compatible with another declaring it as "yes" or "no")
   • ... while preventing others: fields contributed from the same entity type, or from a supertype and one of its subtypes, with the same name, fields contributed from different entity types with the same name and different options
2. This feature could conflict with some support we have for inheritance in 6. For instance if you define a property with type T in entity type A, annotated with @Field, and override the getter in the entity subtype B to have type U (with U extends T), Hibernate Search will correctly look for a bridge taking U as an input. If we have to take into account multiple entity subtypes B, C, D, etc., each overriding the property to have a different type V, W, ... this could get wildly complicated really fast.
3. This feature would make the indexing process more complex. That would be manageable, but the problem is this would consequently make automatic reindexing when a contained entity changes more complex, too. And that part is already quite complex...

Also worth mentioning, part (if not all) of the problematics mentioned above are very similar to the ones we would face if we allowed multiple indexed types to be stored in the same index in Hibernate Search 6. And we decided against it in order to keep things simple and to not have to work around the decisions that were taken in Elasticsearch 6.

So can have a look, but let's keep in mind this has some implications that make the feature far from trivial to implement.
Moving this to version 6 so that we don't forget to have a look.