"Complex chains of dependencies on specific versions" is an anti-pattern, common in the Java world.I do have some sympathy for this radical simplicity which Go aims for, but at times it comes at a cost, and at times a little bit of complexity has to be added to deal with the real world (only very rarely and after much thought though). I'm torn between admiring that they don't rush into new features and impatience with a few small things they've refused to add so far.
If someone deletes your favorite package, then you can just re-upload it from your cache and let people know about the new URL-- assuming that the code is open source.
Well yes, but then you're de-facto maintainer of that package, you might not have permission to do that, etc - this point though I feel is less important than versioning, it's more an argument for central package control, which has pros and cons. I'd be happy if Go never does that and agree that it can be worked around but will be interested to see if people judge it necessary eventually. There's nothing to stop people setting up a central package resource, and nothing really needs to be added to go to support it.
If you want to make a backwards-incompatible change in your library, then just create a new version and call it something (slightly) different. There's no reason to complicate things.
This is not an acceptable solution, it would lead to situations like:
import 'github.com/user/yaml_parser'
import 'github.com/user/new_yaml_parser'
import 'github.com/user/really_new_yaml_parser'
import 'github.com/user/toms_new_yaml_parser'
What a mess, particular for new users trying to decide which package is best or canonical. Why not just use versions?
I wouldn't be so quick to defend the status quo - Go is a young language with plenty of maturation still to do, they could easily add versions to packages if it proves necessary - I suspect in the long term it will, because large ecosystems do involve chains of dependencies (I'm not talking about java here, but perl, python, ruby, java, C++, etc all of these languages version libraries in some way), and developers of packages make mistakes which they need to fix, sometimes by deprecating or removing compatibility, but their users don't want to deal with those mistakes, sometimes for years, and the users of their users certainly don't. Choosing a new name and orphaning all your users is not an acceptable solution.
I'd prefer if package maintainers could just do this:
import 'github.com/user/yaml_parser'
import 'github.com/user/yaml_parser/1.0'
import 'github.com/user/yaml_parser/1.0.1'
etc and left the master as the plain name with version tags as longer names. It'd be nice if go supported this by supporting arbitrary branches or tags on github etc but I don't think it does at present, happy to find out I'm wrong.