From HSEARCH-1872 Pull Request Sent comments:

When querying multiple indices [hence multiple entities] at once, it may happen that some field we're sorting on is absent from one of the indices. In that case, ElasticSearch requires that type information be provided.
So in that case, we may have to retrieve type information from the metamodel. Problem: the QueryBuilder, from which we start building the sort, is only aware of one entity we're working on. This might be something to fix, because queries built this way may (and will) still be ran against multiple indices.
So, let's say the user is querying two indices: A(fields: z, a1, a2), B (fields: z, b1, b2), and he wants to sort on z, then a1, then b1. The user won't be able to build his sort with the QueryBuilder, since whichever entity he chooses to bind his QueryBuilder to, there would be some missing type information at some point (for either the a1 field or the b1 field).

The idea would be to enable creation of a QueryBuilder with a scope covering multiple entities. When retrieving metadata, this builder would try retrieving from the first entity, then (if not found) fall back to the second, and so one.
We would implicitly consider that if a field exists on one entity, on every other entity of the scope the metadata for this field are the same or the field doesn't exist.