Actually this isn't really a go specific thing. If I have a struct defined in a package version 1 that gets an extra field in version 2 how can I possibly reuse that struct between packages.
Yes, that's a problem too, but there's a lot of packages which don't have side-effects (I'd expect more of the latter, in fact).
Your point that there needs to be control over packages that should be singletons and/or "public dependencies" is a fair one (it's something that has been considered for cargo for a while, but I'm not sure it's been implemented yet), but allowing multiple versions for packages without side-effects is a strict improvement over the abstraction-breaking "one version globally" for every package.
> If I have a struct defined in a package version 1 that gets an extra field in version 2 how can I possibly reuse that struct between packages.
You can't: they're different types. The underlying assumption of having multiple versions of a package is that imports have unique (name, version), not just name, meaning "a" v1 and "a" v2 are treated as completely different packages, just like "a" v1 and "b" v2.
That vgo encodes semver as sone sort of contract system is crazy pants on a whole new level.
> Exclusions only apply to builds of the current module. If the current module were required by a larger build, the exclusions would not apply.
I don't think I understand what you're getting at. In ruby I can say I depend on a version > 1.2.0 and some other project could use my package and use version 1.2.1, thus altering my dependency. Bundler lets me do that because it makes assumptions about what version numbers mean.
The lock file makes sure this only changes when I want it too, but semver is an integral part of the system
Yes, in systems like Cargo you end up with multiple versions of the same package. This typically "just works". It works so well, in fact, that often times people don't even realize they're using multiple versions of the same package, and they want Cargo to report an warning here.
> This seems a fairly reasonable tradeoff; on the upside is a _very_ fast, very simple, and very predictable dependency manager.
For other package managers, speed of the core dependency resolution algorithm has never been a problem for me or anyone else I know.