Looking up the what . stands for in go.mod yields "path/should/not/matter"

The go tool doesn't know what to do with this import path.
(BTW: if the module is e.g. git.intern.ourcorp.net/shared/tooling
the go tool will start querying Fetching https://git.intern.ourcorp.net/shared?go-get=1
to no avail.)

What did you expect to see?

I would expect that a GO111MODULE=on go build fails with the same
error message like a GO111MODULE=off go build in a GOPATH layout
namely:

Use the actual loader result in findModule instead of making
assumptions about nesting in the build list.
As a side-effect, this produces much clearer error messages for
packages that (for one reason or another) failed to load.
Adjust the package and module path outside a module to
"command-line-arguments". That string already appears in the output of
a number of (module-mode and GOPATH-mode) commands for file arguments,
and as far as I can tell operation outside a module is currently the
only case in which the module path of a package is not actually a
prefix of the import path.
Fixes#28011Fixes#27099Fixes#28943
Updates #27102
Updates #28459
Updates #27063
Change-Id: I61d5556df7b1b7d1efdaffa892f0e3e95b612d87
Reviewed-on: https://go-review.googlesource.com/c/153459
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>

This comment has been minimized.

This issue appears to extend further - build.Import with build.FindOnly should return the directory path resolved for an import, even if there are no Go files in the directory, but this does not seem to be the case with Go modules.