FWIW, my stack for the concurrency model is still pending. (I was hoping to make progress on it during the Quiet Week last week, but didn't end up with enough bandwidth.)

jsonrpc2_v2 should be stable at this point, whereas the old jsonrpc2 is at least a little flaky (#55179). We should do this migration at some point in the not too distant future.

I almost got to do this, but Alas, the unrelenting pressure of priorities prevented it, and I bailed to implement Async handling in jsonrpc2 (v1).

Here are reasons to make this switch, summarized from my investigation:

• In order to make jsonrpc2 v1 async, we'd need to make the ServerHandler dispatch async, exposing the Replier to gopls calls. (EDIT: we ended up doing this by adding magic jsonrpc2.Async(ctx) calls similar to t.Parallel()
• ...but much of the existing handler behavior is offloaded into middleware: CancelHandler and AsyncHandler. CancelHandler is responsible for handling $/cancel notifications to cancel ongoing requests, but that means it doesn't see $/cancel until its delegate handler has processed prior messages. To solve this problem, the AsyncHandler handles messages (trivially) as fast as it can, enqueuing them onto distinct goroutines.
• Additionally, in jsonrpc2 v1 reads from the network connection are synchronous to handling, which could lead to distributed deadlocks with clients blocked on writing. Here again the AsyncHandler mitigates the problem, though suboptimally.
• Since this logic is implemented in middleware, and not core to jsonrpc2 v1, the AyncHandler builds up a queue of goroutines waiting to handle requests, and we still have to wait for this queueing to get to $/cancel notification. Furthermore, we need to wait for gopls to actually handle the request (albeit with a cancelled context) before we reply to the client.
• This also means that the CancelHandler has to have its own control plane, separate from the jsonrpc2 session lifecycle, which means that closing the jsonrpc2 connection won't cancel ongoing requests.

By comparison, jsonrpc2_v2 exposes the Preempter interface, so that gopls sees the $/cancel notification before it is enqueued. Furthermore, async reading from the network connection is built-in, and requests are always handled asynchronously to reads, on a single dedicated goroutine. Cancelled calls are never seen by gopls. When the connection is closed, ongoing requests are automatically cancelled.