Currently, the go module (dependency) graph contains all transitive dependencies, including from versions which do not end up being the effectively resolved version. While this is unavoidable to some extent (determining the effective version requires traversing and unfolding the graph), the same does not apply for the root requirements: if a root requirement for example.com/my/module v1.2.3 exists, we know that a strictly transitive requirement example.com/my/module v1.2.2 (or any lower version) cannot be a candidate for the finally resolved version. Furthermore, this determination can be made without having to inspect any additional (i.e., other than the main module's one) go.mod files. A similar (but less practically relevant) observation applies to the main module: any transitive requirement for example.com/main/module v1.2.3 can be ignored, as the main module with version "" always wins.

This proposal therefore aims at changing the module dependency resolution algorithm in such a way that every requirement for the main module of any version, as well as any strictly transitive requirement for any other module of a version less than the version directly required by the main module, is treated as if an exclude directive for that module/version combination existed.

This is motivated by the following:

• reduce the clutter in go.sum
• reduce the number of "orphaned" module dependencies, i.e., modules that show up in go list -m all, even though they are not (transitively) required by any module in their respective selected version.
• reduce the amount of manual replace or exclude hackery required in case a project's dependencies module hygiene is suboptimal.

While all of the above problems don't get eliminated by this proposal (they can basically all still exist one level down in the dependency graph/DAG), they should get significantly mitigated. In contrast to more sophisticated heuristics to address these, this proposal is limited to relying on information that is already present in the go.mod file, but not spelled out in replace directives.

This would require compatibility logic for go mod tidy, as the resulting go.sum and even go.mod file output might change, as well as the requirements for go.sum entries that may effect the module dependency resolution throughout.