Using https://pkg.go.dev/golang.org/x/tools/cmd/benchcmp as an example:

$ go version
go version devel +cf59850466 Wed Mar 10 09:01:05 2021 +0000 linux/amd64
$ cd tools
$ git checkout -q 44abc2a71b321b77c0a579d8c5bf2704d648c9e0
$ cd cmd/benchcmp
$ sed -i 's@benchmark/parse@missing/package@g' *.go
$ go build
benchcmp.go:15:2: no required module provides package golang.org/x/tools/missing/package; to add it:
	go get golang.org/x/tools/missing/package
$ go get golang.org/x/tools/missing/package
go get golang.org/x/tools/missing/package: no matching versions for query "upgrade"

What I do here is add an import to a missing package that could be part of the current main module. The example I use is perhaps silly, but it's somewhat common to end up in this situation. For example:

• Rebasing or applying an old patch that imports a package which is now moved or deleted
• Writing an import manually and making a typo

I get why the errors are technically correct. When I run go build, the go tool doesn't know if there happens to be a module with path golang.org/x/tools/missing or golang.org/x/tools/missing/package, which could possibly contain the package needed. And, when I run the go get, it finds no such module, and the main module can't be upgraded to contain such a package.

First, an assumption: nested Go modules are very rare, and should not be encouraged. So I don't think that we should be optimizing the error messages for that use case.

Now, some suggestions from the user's point of view, for this scenario:

1. The go build error shouldn't suggest go get. It's very unlikely that it will fix the problem. If the user really has nested modules that would be fixed with a go get, I imagine they know what they're doing and can figure out what to do.

For example, here's a suggestion:

$ go build
benchcmp.go:15:2: package golang.org/x/tools/missing/package does not exist in the main module

2. The go get error is confusing. For example, see what happens if I try to upgrade the main module:

$ go get -d golang.org/x/tools@latest
go get: can't request version "latest" of the main module (golang.org/x/tools)

Now, compare that with package paths:

$ go get -d golang.org/x/tools/foo/bar
go get golang.org/x/tools/foo/bar: no matching versions for query "upgrade"
$ go get -d golang.org/x/tools/foo/bar@latest
go get golang.org/x/tools/foo/bar@latest: no matching versions for query "latest"

If no nested module is found, I think it should just show the can't request version error, just like go get -d golang.org/x/tools@latest.