I must say I don't fully understand your original question, so I can't answer it directly. However, I can share my (very hand-wavy) thoughts on the general LSP ecosystem, and it looks like that might actually answer your question.
I personally don't believe that NxM is a real problem. If you have an editor, which has bespoke APIs for providing completion, and a language server, which speaks bespoke protocol, binding the two together is not hard. A single person can do that and if, say, at least 1000 people use editor X with language Y, it doesn't seem like a waste of effort to me.
The problem is that writing a language server that works is hard. "Rewrite your entire compiler from scratch" kind of hard. Before LSP, only JetBrains delivered these kinds of compilers consistently. Notable non-JetBrains tools from before LSP era are Roslyn and Dart Analyzer.
The Dart Analyzer project is particularly interesting -- it's the same "separate server process speaking JSON" kind of architecture. The details of protocol are different (as it predates LSP) and it doesn't try to be language agnostic. Dart support in IntelliJ is powered primarily by this server.
In my mind, the main value of LSP is social: it pushes language designers and compiler writers to think about editing and refactoring incomplete code, which is a very different problem from compiling mostly correct code.
I personally don't believe that NxM is a real problem. If you have an editor, which has bespoke APIs for providing completion, and a language server, which speaks bespoke protocol, binding the two together is not hard. A single person can do that and if, say, at least 1000 people use editor X with language Y, it doesn't seem like a waste of effort to me.
The problem is that writing a language server that works is hard. "Rewrite your entire compiler from scratch" kind of hard. Before LSP, only JetBrains delivered these kinds of compilers consistently. Notable non-JetBrains tools from before LSP era are Roslyn and Dart Analyzer.
The Dart Analyzer project is particularly interesting -- it's the same "separate server process speaking JSON" kind of architecture. The details of protocol are different (as it predates LSP) and it doesn't try to be language agnostic. Dart support in IntelliJ is powered primarily by this server.
In my mind, the main value of LSP is social: it pushes language designers and compiler writers to think about editing and refactoring incomplete code, which is a very different problem from compiling mostly correct code.