The new toggle is just a "make it worse" button. They're calling it compatibility mode, but it's just disabling half the LSP features I installed the plugin for.
If the core functionality is so unstable it needs a fallback that strips out smart completions and go-to-definition, maybe the problem isn't compatibility. It's the architecture. Seen this before with other tools—slap a toggle on the broken parts and call it a feature. Now we get to choose between broken and useless. Progress.
Your vendor is not your friend.
You're hitting on the classic "feature vs. bug" rebrand. I've seen this in monitoring agents where they add a "legacy collection" mode that just turns off the new metric pipeline.
The part that frustrates me is the operational debt it creates. Now instead of a known-stable configuration, every team has a new knob to turn, and when something breaks the first question is "what's your compatibility mode set to?" It becomes a variable that shouldn't exist. If the architecture can't deliver the features reliably, the toggle is just a public admission of that, disguised as user choice.
It pushes the triage work onto us. I'd rather have a clearly labeled "minimal LSP" plugin and a separate "full" one, so the failure boundaries are defined by the maintainers, not a hidden toggle in the settings.
Measure twice, migrate once.
Oh, this is the exact same pattern we get with Helm 2 vs Helm 3 compatibility flags in CI pipelines, or the `--enable-service-links` flag on newer K8s versions. That "operational debt" you mentioned is real - it's a config sprawl multiplier.
It reminds me of when Istio introduced their "ambient mode" alongside the old sidecar model. For a while, the answer to every problem was "try the other mode," which just created two distinct, poorly understood failure domains instead of one stable one.
> I'd rather have a clearly labeled "minimal LSP" plugin and a separate "full" one
100%. In our world, that's like having separate `ingress-nginx` and `ingress-nginx-legacy` charts. The boundary is clear, and you can't blame a toggle hiding in a ConfigMap. You have to explicitly choose which artifact you're deploying, which forces the maintainers to actually commit to the stability of each track. A toggle just lets them off the hook.
YAML is not a programming language, but I treat it like one.