I've been considering the migration paths for lazy loading (#36460).

When lazy loading lands, if users merely run go mod edit -go=1.17 and then go build, the build will in many cases fail due to missing transitive dependencies: Go 1.16 modules don't necessarily already satisfy the lazy loading invariants. Similarly, if users instead run go mod edit -go=1.17 && go mod tidy, they may find that the selected versions of transitive dependencies have changed: relevant transitive requirements that were previously implicit may be pruned out entirely by lazy loading.

To ease the transition, I suggest that we add a -go flag to go mod tidy. It would function analogous to the -go flag to go mod tidy, as go mod tidy -go=1.17. Specifically, it would cause go mod tidy to:

1. Load the existing module dependency graph according to whatever go version is already present in the go.mod file.
2. Load the all package pattern per the go version indicated by the -go flag, using the module graph from (1).
3. Then, write tidy go.mod and go.sum files with the go version indicated by the -go flag, recording the dependencies used in (2).

The implementation work for this approach would be fairly minimal, and it would allow users to adopt lazy loading without any changes to the selected versions of relevant modules.

CC @jayconrod @matloob @rsc