Thank you for filing a gopls issue! Please take a look at the Troubleshooting guide, and make sure that you have provided all of the relevant information here.

My personal recommendation would be something in the middle, hashing a few known-common things to get most of the cases correct and leaving the rest to documentation/warnings. Off the top of my head I would think this list for the average user is:

• go version (build ID?) - changes on Go upgrades
• go env GOROOT (maybe GOTOOLDIR?) - often lives in different folders between versions on Linux distros
• Maybe go env GOPATH

Many other things can end up mattering (GOPACKAGESDRIVER, cgo-related options, GOPROXY/GONOPROXY which may have security implications) but are much more likely to have been explicitly set by a person who understands the impact when these values change and knows how to deal with a warning.

We can still set environment variables used by gopls in calls to go/packages so I don't think it's critical to include those in the instance key.

My two cents: keep things super simple for the majority (for now), and experiment with making the caller do the hard work if they want to handle more complex situations. This is, incidentally, why I requested support for what @findleyr kindly delivered via -remote=auto;id. In my case I use process mount namespaces for different go versions, hence the ID I use will at least include a hash of the significant mounts (one of which includes Go version). But the onus is always on me as the caller to derive the ID by hashing whatever I want to be the key. Not least because gopls can't determine what should/shouldn't be in the ID in all cases.

This way if patterns of usage start to emerge where lots of people are running into problem X then we could look at have -remote=auto automatically hash A, B and C.

experiment with making the caller do the hard work if they want to handle more complex situations

My issue with this approach is that I think gopls knows much better than the client what things could affect the analysis. I think there are a few things that are common enough that with that approach, every client's going to be doing some hashing if they want to work around environment-related issues.

Not least because gopls can't determine what should/shouldn't be in the ID in all cases.

Which cases would gopls not know? The example you've given is Go version, which gopls would know, but I'm curious which other things you think might also affect the ID that only the client would know but would still affect gopls internally.

My issue with this approach is that I think gopls knows much better than the client what things could affect the analysis

I completely agree with this point. I'm very much in favour of having zero logic in the client/editor. The distinction I draw here is that it's the user who is necessarily defining the key, because the client/editor also can't know.

Which cases would gopls not know?

Basically any path. e.g. where go env GOPATH is the same value, e.g. /path/to/gopath, but because of process mount namespaces (or FUSE file systems or whatever) that path points to a different actual/real (terminology?) location.

My personal recommendation would be something in the middle, hashing a few known-common things to get most of the cases correct and leaving the rest to documentation/warnings.

That seems reasonable. Here's what I'll do: first, I'll create a key-value map of environment values that affect execution, compare them in the handshake, and raise an error if there is a mismatch. Then we can wait for people to complain that this error occurs under normal operation, and in those cases we can hash the environment value in question into the daemon path.

Enough people use different versions of the go command to warrant including this in the daemon path. Hashing either go version or go tool buildid $(which go) would work.

Change https://golang.org/cl/234109 mentions this issue: internal/lsp/lsprpc: forward the go environment in initialize requests