Well for one I wouldn't design it so both the LSP and the editor need a synchronized view of the underlying file.

One of the largest issues of LSP is that each language implementation needs to do everything separately, and that means each language will work differently.

Imagine if all the editing tools in microsoft word were specific to the language you used, and if you mixed German and English, each had different tooling.

Now if you mix Rust, HTML, JS, and CSS, they'll all have separate tooling, seperate "go to definition", and separate refactoring. Worst of all, none of them can see the definitions of the other ones.

So what you'd actually want to do is parse each language into your AST, with proper annotations as to what is what, and have all the "go to definition", the UI rendering, highlighting, refactoring, etc all done generically by the IDE ontop.

Which is much much closer to how Jetbrains IntelliJ does it, and why their tooling can handle "find usages" on an HTML element to find matching querySelector in .js files and matching selectors in .css

And if you subscribe to the AI stuff, you'd also want your AI to operate on this AST so it can learn skills that generalize across all languages.

Wouldn't a normalized protocol based on AST vocabulary and tree operations make more sense ?

Start with synchronous function calls instead of JSON. Microsoft knows how to do that - they invented COM and OLE. Function calls enable whatever data sharing is necessary to maintain a coherent view. Imagine trying to do OLE with JSON - just wouldn't work. (Does OLE still exist?)