Spec does not specify if and how multiple registrations for the same method will be handled.

In Register Capability, the spec reads

Server must not register the same capability both statically through the initialize result and dynamically for the same document selector.

(It would be nice to clarify what happens if no document selector is available but that is not my issue here).

Now this implies that it is okay to register for the same capability if you use different document selectors. However a DocumentSelector is a list of DocumentFilter so ever if two document selectors are different, they may still contain the same filter, or different filters that can still match the same document. Also, multiple dynamic registrations seem to be okay even with the same document filter.

So, what is the semantic here? Will a new registration for a method m replace a previous registration for m? Will both registrations pile up? If so, will two requests be sent when a document matches the selectors of multiple registrations? How can the server know which registration caused the request to be sent?

I think there are two possibilities to answer these questions:

• Either the spec defines that only one registration can be active for each method. Then the server always knows which selector triggered a request.
• Or the spec defines explicitly that multiple registrations are okay for each method. Then, the server should have a possiblity to check which selector triggered a notification (either by sending a list of registration ids in one request, or by sending multiple requests with a different registration id each). If the client does not provide this option, the server would need to replicate the document selector filtering which does seem superfluous if the client already did it.

In any case, the spec should be clear about what happens in this case. Currently, I can't find any information about it.

Start with the Register Capability section and its references to the initialize result, DocumentSelector, and DocumentFilter. Trace how the specification currently describes static and dynamic registrations, then resolve and document duplicate-registration behavior, including request routing and registration identifiers. Done means the specification unambiguously defines these cases.