Defensive issue. The zero-config behavior added in #57979 means that gopls works in a lot of cases where it didn't work at all before. In particular, with dynamic build tag support (#29202), gopls will select build contexts to cover a lot of files that it couldn't previously load.

I'm excited for the simpler workspace configuration, but I worry that the newly automatic behavior may be surprising in some cases, for example #65496, where gopls "correctly" identifies a build error in an unsupported port. Additionally, while all this was enabled by our scalability work, having many different build contexts still incurs an overhead, and that may not be desirable in some huge repositories.

I think we should proceed with the new default behavior -- after all the idea was to make gopls "just work" in more cases -- but I think we should add hidden settings to disable (1) dynamic workspace views and (2) dynamic build tag support, in case users encounter unforeseen issues. My guess is that dynamic workspace layout detection is almost always desirable, but build tag behavior is more likely to be confusing.

This won't be hard: we just need to truncate the selectViewDefs algorithm if these defensive settings are present.

CC @adonovan