And a bit over a year after your post I stumbled over the same issue
The link you shared was interesting, they want us to put a go.mod into a v2 subfolder. I think that’s quite debilitating in regards to easy updates and releases in those repos (I don’t even start with mono repos).
I thought that the easiest way (see my two links I found) would be to add /v2 at the end of the module call in go.mod, but that too is very inconsistent and often results in weird v0.0.0-githash versions.
What I did to get this out of the way and out of my mind for now is to violate semver. My versions are now v1.major.minor.patch as in v1.2.0.2. It’s dirty, but to be honest, I think the inventors of this versioning thing are either former theoretical philosophy students that got thrown out and try to abstract the world now in IT or there is some weird hidden deeper meaning. Secret society and such.
Anyway, that won’t help you, but try to stay on v1 and do semver in the 2nd to 4th part is my (hacked) advice.
This is only for major version changes, and is possibly the most controversial things with Go Modules. That said, it does allow you to import multiple major versions of a module into a project (if that, for some reason, would be needed (I could see some use cases, if you want to build historic versions of your content)).