I realize I'm a bit late for #24301 but I wanted to mention/ask about preserving the ability to make (usually small) edits to modules that your code depends on and be able to commit these easily back to the repository. I believe this is still possible with what is currently planned (since it will, for now, still use git or svn or whatever) but as mentioned in the various conversations moving away from using specific version control commands - that would also remove this ability.

Use case: You are developing a large application A for a client and while doing it you encounter a problem that needs a module M to solve that specific problem. It's not specific to the client, it's a general problem and you want to make an open source library for it (presumably on GitHub). You make a rough version of module M and put it on GitHub as a v0/prerelease. Module M passes its own tests, a minimal set made in order to get started. You incorporate into application A, and two weeks later it crashes due to an a-bit-harder-than-usual-to-catch bug, e.g. double-locking a mutex, unchecked map writes, or even issues outside of Go's control like remote file system locking/race condition issues - or some condition you don't understand yet, all you know is "I used this in production and it crashed". In order to solve this problem, you might need to spend a good amount of time trying changes to module M to find and resolve the issue. Editing and testing module M in its own project by itself may not be feasible because the bug does not reproduce with simple test cases - only when invoked from application A. In this case, having to do a commit and push for every single change you want to check for module M would be unduly onerous. (There is also an expediency argument in favor of being able to do small changes to M while working on A, but the case where you literally can't test without running A is more important.) While I realize this isn't the most common case, I've run into enough that I think it's worth looking at.

One possible solution would be to preserve an option in whatever command(s) are fetching modules to fallback to the VCS-specific commands as opposed to using some other VCS-agnostic protocol - and preserve that functionality as a supported way of doing things if the developer still wants it.

Edit: It would also solve this issue to just have some kind of assurance that if I go into $GOPATH/src/path/to/project and replace what is there with a git clone that invocations of Go tools will not clobber my local changes (or at least not without asking me or requiring a -f flag or similar).