Here's what I think is going on:

If you change the major version in go.mod, you also need to change the major version in the import path (in the .go source files). Only v0 and v1 can have unversioned import paths (see https://research.swtch.com/vgo-import), which is why vgo accepts v1.3.7 initially.

When you change the version to v2.2.6, vgo checks for a corresponding tag or branch in the repo. It successfully finds a tag in the repository, but without a semantic import path it isn't willing to consider that to be an actual major version: it can't coexist with some other major version at the same import path. So instead, vgo resolves the tag to a commit (947dcec5ba9c) and records that commit itself as a “pseudo-version” (see https://research.swtch.com/vgo-module).

When version selection occurs, the pseudo-version commit will be used to resolve the v0 import path (that is, the import path without a major-version component), not the v2-suffixed import path (which will be resolved separately).

That makes sense, but IMHO this needs to be fixed in vgo, a lot of repos are already using v2+ tags, not adding a way to support them and assuming they will add vgo support on their own is really gonna be painful to deal with.

The pseudo-version in the updated go.mod file is the version tagged v2.2.6 in the repository: you got the commit you asked for, just by a different name. Is that causing an actual problem for you otherwise, or just confusing to see in the go.mod file?

It's rather confusing that vgo modifies the file on read-only operation (vgo list, vgo build, etc).

@bcmills #25412 explains it better than me, while it is a dup of this, his explanation is much better than mine so feel free to mark this as a dup of it.

Ok, will follow up on #25412.