Catching up on some questions:

The new API should support:
sort by relevance / score and doc id / indexorder
sort by multiple fields

+1 remember also to make it possible to use multiple fields of different "type", e.g. to sort both by distance and by surname.

do we need to express field type? We know it, no? What about non mapped fields?

Yes it would be lovely to use our metadata. For non mapped fields, I'd use a strategy consistent with the Query defining DSL: we do the right thing on the known fields, but for the unknown fields we'll assume that the user is giving the right options.
This used to be a bit confusing with the Query DSL though; so while I'd favour consistency with it, I think it could also be fine to simply state that the Sorting DSL can only be used with mapped (known) fields. People should still be able to fall back to the "power users" version using Lucene / ES native APIs.

allow to pass custom comaprator (has to be script for ES)?

Maybe only in future? I'd keep our DSL simple and targeting the simple use cases, people can use the native APIs for the more exotic needs.
Also a custom comparator would probably break on the compatibility whims of upgrading Lucene / upgrading ES versions so I think it would be nice to "draw the line" of what Search helps with in terms of stable supported APIs vs when the user is using something "native".

support missing value (first, last, custom value when absent) => native Lucene seems to have more limitations on the custom value than ES.

+1 but let's only expose on the common API what is clearly supportable by both.

sort mode for multi values (min, max, avg, sum, median) => is it supported by native Lucene?

I think it wouldn't be too hard with a combination of collectors and custom comparators but I'd keep this as an optional feature for the future.

reverse order
sort by distance of a point (Coordinate and lat / long)
sort by distance with custom distance computation (distance_type in ES), what about Lucene native?

I'd not expose custom distance computation on this API.

sort by distance from multiple points provided and multiple points in the documents (multi-value)? (that's ES)
a way to back up to native Sort or Elasticsearch JSON "sort" for advanced use cases

It's a good point but I'd rather leave the API open for further extension. We're not removing the current capabilities to use "native sort" ? I think people with special needs should use that rather than the DSL, as I don't see how we can promise automatic type conversion and all that while keeping it both correct and easy to use.

Does it make sense to sort by SCORE and then by a specific field Sanne Grinovero ?

Sounds like one would rather customise the scoring? I'd again leave such odd needs to the existing and/or APIs, to not encourage it.

Does distance support missing value? Can it? And if yes, is it limited to first / last?

I'm not sure if that would work. I guess missing coordinates might be interpreted as some specific zero coordinate, but that would still be treated as a specific position. The first/last part probably doesn't make sense as it's on a sphere...