Thanks, good points. I agree on pairing the two. The "why" section touches on this: go mod why -m follows the package import graph, and the requirement graph shows which chain of go.mod files brought a module in. When you're deciding what to cut, the import chain is the one to act on.

The pruning note is a useful addition. Since Go 1.17, the graph leaves out the deeper requirements of modules that declare go 1.17 or later, so the same project can show a much smaller graph than it did on older Go versions. Worth keeping in mind when comparing graph sizes across projects.

And yes, the cycle in the article is a requirement cycle between the otel modules, which Go allows. An import cycle between packages is a compile error, so the compiler already catches that one.

Glad it landed. And good confirmation on the otel requirement cycle — exactly the kind that slips past you in a monorepo, since Go won't stop you from building one.