Having said this, I think some sort of query language is also very useful, but both features can and should coexist. And it seems fine for the query language to exist in a third party tool.

The syntax for this is a bit tricky. With a single path, the output can just be the nodes (packages) along the path. With the complete import subgraph, we would presumably need some way to show the edges too.

But I guess go mod graph does already have a format for edges...

What I was initially thinking would be to expand the newline-separated output with the possibility for many empty-line-separated groups:

$ go mod why baz
foo
bar
baz

foo
some-other-bar
baz

Another option could be to piggyback off of the go mod graph edge format, so that we would just show the sub-graph for all paths that reach the destination:

$ go mod why baz
foo bar
bar baz
foo some-other-bar
some-other-bar baz

I personally prefer the first, because I find it easier to understand for a human.

I don't think groups are viable in general: even neglecting cycles (which are possible with build constraints), the number of unique paths is exponential with the number of nodes in the worst case.

Then perhaps the answer is to provide a go mod graph that spits the output for the package import graph, not the module dependency graph. Then one can visualize, query, or inspect that as needed.

One can get that information via go list -deps -json all, but it requires more work. And any tools which currently understand the go mod graph output could easily work out of the box.

An extra thought - the package variant of go mod graph should accept the usual build flags and arguments. Using go-pkg-graph as a placeholder for the sake of the examples:

# the entire graph for all packages here
go-pkg-graph ./...

# only the sub-graph with the current main package at its root
go-pkg-graph

# same as the above, but with different build params
GOOS=windows go-pkg-graph -tags=purego