Honestly, most package managers just bring their own problems. I'd rather commit source code than troubleshoot npm, pip, nix, maven, etc errors all day long. The only package manager I've found that works reliably has been Cargo (Rust).
There has been a lot of talking between the committee that created `dep` and folks who've implemented other systems, including Cargo. I have high hopes.
I believe the current intended use is a human-editable "manifest file" where you specify desires/intent, preferably semver, ideally only as necessary, and a machine-generated "lock file" which specifies the actual hash of every transitive dependency, so builds are fully specified and reproducible.
But they all have to vendor as well if they want reliable builds. Otherwise you end up with everything breaking when a developer decides to do a forced push or take his repo off github.
Force pushes - by far more common than straight-up repository removal - are handled without problem; we let you stick with your old version. (At least, that's how it should be - there might be a couple more test cases to write. I know I designed for this problem early on).
Repo removal, renaming, or whatever, are still problems, for sure.
Today, dep populates vendor/ with dependencies, and works equally well whether you decide to commit them or not.
When dep removed the vendor folders from the other libraries, How does dep handle multiple libraries that depend on the same library but different versions of it?
Are you checking your dependencies into your repository (we do this, it works very well).
If not, are you pinning specific commit hashes? Is that even possible in Glide?
AFAIK those are the only two ways to get even close to reproducible builds.