Question: if the goal is to communicate to vgo, what should vgo (the build system and MVS) do with this information?

If communicating with a user I would say v2.0.0-unstable-1

Question: if the goal is to communicate to vgo, what should vgo (the build system and MVS) do with this information?

I'd say treat it as vgo does pre-1.0 versions. In particular don't assume semver compatibility promises. (But maybe I'm just confused about all of this. Wouldn't be the first time.)

vgo, the build tool and mvs, doesn't care about compatibility. It does care about semantic import paths which allows v5 to be a different package then v4.

I don't think that matters to the vgo build tool. It would matter to a hypothetical "go release" compatibility checker tool though.

Could you not make the breaking changes on a branch (could be master), where the go.mod on the branch has the /v2 (or whatever major version you're at) added. Then use vgo get example.com/hello/v2@branch_name to use v2 (in this case) pseudo-version?

One of the confusion I had (and still have) while reading vgo blog posts is the relationship between the samantic version import and the semver looking version tag used in go.mod.

According to @myitcv's comment, I assume we can even continue using golang.org/x/debug/v2 with v0.0.0-(utctime)-(commitid) convention. Similarly golang.org/x/debug can be tagged with v999.0.0, which matches one of the examples in the 6th blog post. Am I misunderstanding it?

I'm not sure how vgo plans to handle this, but per semver, versions such as 2.0.0-alpha or 2.0.0-alpha.2 are supported in the spec.

@josharian That comment was in the context of the x repos, where we are still working out what the general plan is for tagging versions (more complex than most because they are kind of monorepo-esque). If actually tagging things was an option (we're just not ready yet) then we'd put a v2/go.mod there that said module golang.org/x/debug/v2 and either not issue any tags at all (in which case it would be all pseudo-versions, and you get what you get) or use tags like v2.0.0-unstable-SOMETHING. That kind of prerelease semver tag is how you opt out of compatibility, which is what I think you meant instead of "opt out of semver". The strongly worded README is only necessary because we haven't finalized plans for golang.org/x.

@hyangah If the module path ends in /v2, then the version in go.mod must begin with v2. For a v2 module you'd use a pseudo-version that was v2.0.0-time-commit instead of v0.0.0-time-commit.

golang.org/x/debug can be tagged with v999.0.0 but unless there is a go.mod there saying module golang.org/x/debug/v999 and the code is imported that way, that tag is not going to be used by vgo.