I the context of versions I think Rickey puts it best, actually there are no guarantees of compatibility.
Even a minor update can eventually break someone's code that relied on the bug.
"Spec-ulation – Rich Hickey"
In all big packages I use: yes, it is. This is actually a must given there was no (standard) version management system. If you have no versioning system and don't make your code backwards compatible, you break someone else's code. So, either you make a new repository, or you make a subpackage in your current repository with the new, breaking version.
------------------
Not a Go dev:
Is the mantra of "the new package must be backwards compatible with the old package.", which is an underlying requirement for vgo to work, actually followed in the Go ecosystem? It seems crazy to me that a package would have to change its name if it wants to introduce a backwards incompatible change.
Has this happened in practice? How does it work? Are people going to suffix packages with "Really major major" version numbers separately from the actual version number?
The criticisms of bundler in the proposal seem to be be a bit wierd when the solution is to force a new paradigm on developers to make vgo's job easier.
Why even use Semantic versioning at that point since a major version can never be incremented.