I still, for example, can't get Zed / LSP to provide auto-fix suggestions for missing imports. (Which seems like a common stumbling block: https://github.com/zed-industries/zed/discussions/13522, https://github.com/zed-extensions/java/issues/20, https://github.com/zed-industries/zed/discussions/13281)
I'm sure given the breadth of LSPs, that they all have their own config, and use different project config files, makes it hard to document clearly. But it's an area that I hope bubbles up the roadmap in due course.
The newer specs for json-schema (not supported by VSCode) allow for a wider range of data requirements to be supported by a schema without that schema resorting to costly workarounds. VSCode's level of support for this is decent, but is still a pain point as it creates a sort of artificial restriction on the layout of your data that you're able to have without unexpected development costs. This of course can lead to missed estimates and reduced morale.
I understand that very few developers are directly producing and maintaining schemas. Those schemas do have an impact on most developers though. I think this is a problem that is being sadly overlooked, and I hope you can consider changing the status quo.
Love the company name btw, sounds similar to my own Nuzz Industries (not a real company, just a tag I've slapped onto some projects occasionally as a homage to Page Industries from Deus Ex).
Right now you can run multiple language servers in a single project. Admittedly you cannot have multiple instances of a single language server in a single worktree (e.g. two rust-analyzers) - I am working on that right now, as this is a common pain point for users with monorepos.
I would love to hear more about the problems you are having with running language servers in your projects. Is there any chance for us to speak on our community Discord or via onboarding call (which you can book via https://dub.sh/zed-c-onboarding)?