The module is defined by a go.mod and the files in that directory and below, not by files above.

This corresponds with how I think about modules. Because after all, directories (and their subdirectories) containing modules can appear anywhere: the only things that cares that they are properly nested is vgo list from a parent directory (this could ensure consistency, not sure whether it currently does) or vgo itself when resolving modules (ultimately from a VCS), per Russ' comments.

That said:

... then it should be irrelevant after commit too

Did you mean "after push/release" here?

Because I think the rest of your argument gets at an issue I was thinking about earlier, namely having some sort of tooling to verify offline, pre-push (release) that your modules are nested, tagged etc as you expect. For custom import paths this would need to be combined with some sort of injection of <meta> tags (because again, you want to test everything offline before the big "push").

Quite how this overlaps (or not) with the proposed "release" tooling I'm not sure.

Equally I'm not sure how well this maps to (company) setups where there is a more involved release process.

@bcmills just to pick up on the point I made above:

the only things that cares that they are properly nested is vgo list from a parent directory

Just to make explicit the "disconnect" I was alluding to:

$ mkdir pkga
$ cd pkga
$ cat <<EOD >pkga.go
package pkga // import "example.com/pkga"
EOD
$ vgo mod -init
vgo: creating new go.mod: module example.com/pkga
$ mkdir pkgb
$ cd pkgb
$ cat <<EOD >pkgb.go
package pkgb // import "banana.com/pkgb"
EOD
$ vgo mod -init
vgo: creating new go.mod: module banana.com/pkgb
$ vgo list .
banana.com/pkgb
$ cd ..
$ vgo list ./...
example.com/pkga
example.com/pkga/pkgb

But I'll note here that we are looking at packages, not modules.

Another interesting case:

$ mkdir pkga
$ cd pkga
$ vgo mod -init -module banana.com/pkga
vgo: creating new go.mod: module banana.com/pkga
$ cat <<EOD >pkga.go
package pkga // import "example.com/pkga"
EOD
$ vgo test
testing: warning: no tests to run
PASS
?       banana.com/pkga 0.001s [no test files]
$ vgo list .
banana.com/pkga
$ vgo mod -json
{
        "Module": {
                "Path": "banana.com/pkga",
                "Version": ""
        },
        "Require": null,
        "Exclude": null,
        "Replace": null
}

Both examples demonstrate there is (currently) no import path checking for packages "within" a module (else both would have failed).

Not sure whether this is related or not (or whether it's "broken") - just adding another data point.

The go command today does NOT go poking around for version control system metadata in the directories where it finds local source code (except legacy "go get", which is going away), which would be required to detect this problem. I strongly believe it should continue to be ignorant of version control system metadata.

I could see an argument for walking up the file system to look for a parent go.mod that conflicts with the current one, but what if you just want to try something out and do:

mkdir _test
cp -a * _test
cd _test
go build, etc

We shouldn't disallow this. Or even if you are moving to a subdirectory development mode and do

mkdir v2
cp -a *v2
cd v2

to play around and see how that would work: should you have to delete all the parent files just to try something out?

The error messages for when this does happen are now dramatically clearer than they were. Let's close this until we find evidence that they're not good enough on their own.

Another good place for a check like this would be the eventual "go release", but that doesn't exist yet. I created #26420 and listed this check there.