Elsewhere I believe @rsc said that it was a design mistake to have the "go" command directly call the git/bzr/hg/svn executables, because that effectively requires either 1) all users to have all 4 tools installed, or 2) force the ecosystem to all use the same tool (e.g. git, like today). Good luck being a Go user wanting to put your source code up on the Internet with bzr. The ecosystem will be annoyed.

True, and I complete agree with that going forward, however, having an optional flag / variable could ease the transition until suitable long-term workaround are in place for the scenarios referenced.

Since we now embrace versions, we can also embrace version tarballs. lots of those tools can dynamically generate a tarball url for a given tag.

We're not going to fall back to the legacy version control tools, for the reasons Brad mentioned (also at https://research.swtch.com/vgo-module).

That said, I would be happy to support version control servers that are willing to speak simple HTTPS REST APIs to tell vgo what it needs to know (pretty basic queries plus fetch me a specific file or a tgz/zip at a given commit). I haven't looked into which ones do that.

Rest assured that we will find some way to make it easy to use local servers. We know the whole world isn't on GitHub.