Indeed in the original ServiceManager we purposely did not care about having several implementations of a given contract.

Is it a service manager in this case? (I understand there is probably no objective answer to that)

From what I understand the need to split contract and implementation is driven by the serialization implementation use case, correct?

Yes

I wonder, do you have other use cases in mind? The backends?

Yes. I also think that class loading might become a service.

Do you plan to have a general purpose way to decide which impl to use for a given contract?

Right now, only a single impl is allowed. However, I discussed with Sanne Grinovero that we might be needed an additional requestService method which allows to specify a specific contract, eg via a String param. So we have a solution for this, if the need arises.

You mentioned ServiceLoader which has IMO a less than elegant way of doing it

How come? It is the standard way of doing it. Also the ServiceProvider code was using it.