With the rise of agents and folks doing more concurrent work on projects than ever, as well as agent harnesses adding more LSP support it becomes pretty common for folks to have a bunch of rust-analyzer instances running, which in turn will have a bunch of proc-macro servers running (if one configures r-a to use multiple its even worse). In my opinion, rust-analyzer would benefit quite a bit from us daemonizing it per toolchain, that is we'd only spin up a proxy per client that then talks to the actual server process, allowing us to deduplicate a decent chunk of state as well as reducing the amount of concurrent system resources. An interesting outcome of this would be sharing of cross client workspace dependency analysis results as well as VFS content, especially when it comes to the standard libraries. Additionally, as we will likely add an MCP server to r-a soon after all we could then expose that MCP interface without having to spin up yet another r-a instance that just loads what is already loaded by the LSP client as well. Naturally not all is well though, there is a specific issue with the LSP and its open/close documents invariants (what we call `MemDocs` internally). That is when a client "opens" a file, it becomes authorative of the files content. That means, multiple clients could own a file in this manner, with daemonizing this we now have the issue of deciding who is actually authorative of the file as we can only consider one of them as the current state of the file. In practice, this should not really become an issue I think especially if we consider crates-io and std source files as immutable (in which case we should discard the memdoc concept entirely imo). Note there is precedent for this already, https://codeberg.org/p2502/lspmux