As of today, it is required to hardcode the full import path of dependencies in each go file, this proposal is to define an alias for the dependencies directly in the go.mod file and to use it throughout the code.
I agree that this proposal breaks the principle you mentioned; nevertheless, using the aliases is not mandatory and, if used, a warning message at build time can inform that the code will not work without vgo.
Right now, the library maintainers decide the minimal Go version supported, precisely in the same way each library can choose whether to use the feature or not.
I think this is an acceptable compromise for a feature that could free the developers from the annoying problem of the hardcoded repository paths in the code.
Besides, the aliases can be used with no drawbacks in every application that is not supposed to be imported as a third party dependency. For example, in my company, we would definitely use this approach for all our web applications.
I also do not like the way that the paths are hardcoded. For example in Angular 2+, I can move any module to a new location or to a new application without any changes. And in Golang I have to do a search and replace all the files to replace all the paths.
We know the workaround; we would like to have a solution instead. Also, It's a matter of personal taste, but from my point of view, the search-and-replace workaround is indeed quite burdensome and risky too.
As another example, Go import paths are URLs. If code said import "uuid", you’d have to ask which uuid package. Searching for uuid on godoc.org turns up dozens of packages. If instead the code says import "github.com/pborman/uuid", now it’s clear which package we mean. Using URLs avoids ambiguity and also reuses an existing mechanism for giving out names, making it simpler and easier to coordinate with other programmers.
Per text @bcmills quoted, vgo is working as intended. While it may be true that you can solve everything in computer science with another level of indirection, new levels of indirection also add new complexity in understanding the system. We're explicitly avoiding an indirection here, by design.