This is not directly related, but I think Microsoft regrets the commoditization of language editing features via LSP.
In hindsight, editor independent language IDE features driven via a client-server model are such an obvious idea - to the point that I wonder why it took so long for this model to emerge. It makes so much sense to build the IDE features a single time, ideally re-using parts of the compiler infrastructure.
By now a lot language servers exist. They have various levels of quality, and the purpose built solutions like VS or the various Jetbrains products are often markedly superior.
But many of them are more than good enough for a lot of developers, and they allow turning even Vim into a full-featured, powerful editing environment. (Neovim 0.5 has built-in LSP support)
This all started out with VS Code, Typescript, and the LSP specification, and Microsoft deserves a lot of credit for kicking off this trend.
But something that probably started out as a way to popularize VS Code and Typescript has turned into a movement that makes the chosen editor much less crucial and more of a commodity.
This almost certainly wasn't the intended outcome, or at least a side effect that wasn't anticipated.
Hence also the recent steps to counter this trend, like restricting the new Python LSP or this newest .NET drama.
Microsoft earned back a lot of good-will from developers with Typescript, VS Code, .net core, Github, npm, .... Many younger devs have lost the mistrust and disgust that was common in certain spheres not that long ago.
They probably feel confident enough now to shift gears and aim for lock-in and control.
LSP is a solid concept, but if you did want to commodify IDE features, it leaves a lot to be desired.
I am implementing an LSP for a pet language, and the state of the documentation is quite shocking. When I first read the "spec", I thought surely I must only be at the intro/marketing brief since so many details are missing.
This is a JSON-RPC protocol and the documentation for all the object types is written in typescript. There's nowhere you can go to see a list of all possible json messages in json. And as you get farther into it, it feels less like a generally designed protocol and more like an interface to vscode in particular.
In general I wanted to use SublimeText and nvim as test benches for my LSP, but in the end I gave up because there were too many subtle gotchas when not developing against vscode itself using the base test project MS provides.
Don't get me wrong, I think LSP has been a great thing for the industry, but I suspect the actual goal was to commodify this type of editor plugin so other competing editors would not gain an advantage over vscode, and to do that in such a way that the result will generally be better on vscode.
In hindsight, editor independent language IDE features driven via a client-server model are such an obvious idea - to the point that I wonder why it took so long for this model to emerge. It makes so much sense to build the IDE features a single time, ideally re-using parts of the compiler infrastructure.
By now a lot language servers exist. They have various levels of quality, and the purpose built solutions like VS or the various Jetbrains products are often markedly superior.
But many of them are more than good enough for a lot of developers, and they allow turning even Vim into a full-featured, powerful editing environment. (Neovim 0.5 has built-in LSP support)
This all started out with VS Code, Typescript, and the LSP specification, and Microsoft deserves a lot of credit for kicking off this trend.
But something that probably started out as a way to popularize VS Code and Typescript has turned into a movement that makes the chosen editor much less crucial and more of a commodity.
This almost certainly wasn't the intended outcome, or at least a side effect that wasn't anticipated.
Hence also the recent steps to counter this trend, like restricting the new Python LSP or this newest .NET drama.
Microsoft earned back a lot of good-will from developers with Typescript, VS Code, .net core, Github, npm, .... Many younger devs have lost the mistrust and disgust that was common in certain spheres not that long ago.
They probably feel confident enough now to shift gears and aim for lock-in and control.