@sdboyer
You're right - they are not. Which is why I never said they were "required," or "needed." Necessity is not at issue; the question is whether or not they have supplemental information that makes it easier to determine compatibility.
It certainly makes it quicker, but I'd argue less accurate and more prone to error than analyzing the code to determine what's actually compatible (API wise).
...well, this weirds me out, because this is pretty close to what I'm arguing for.
I want authors of packages to use descriptive version tags/branches (semver would be a nice standard as @davecheney pointed out) for what they are developing and to specify the specific versions of their deps (e.g. vendor.json, Godeps.json). The specific versions are the only ones the author has tested with / believes to work with their package. The range argument, to me anyway, relays: "I think versions ~>1.2 works with my package, have fun resolving the ambiguity and have fun figuring out what I tested with." Also as someone who needs to consume this information to build people's code I do not want to have to choose which versions to install for them, hence why I'm a firm believer in checking a populated vendor/ (or Godep workspace) into vcs. It eliminates several build time issues (transient network issues, dependency resolution, etc) and promotes repeatable builds.
In my view dependency ranges make it easier for a human being to eyeball compatibility. It doesn't actually designate anything about compatibility in an absolute sense. Here's my analogy: An experienced carpenter can eyeball 12" (specify a version range) and get it right most of the time, or close enough for most work. I'd rather that carpenter use a measuring tape (specific commit/tag) so my house doesn't fall down when he's off by .5" (version range match, but broken API compatibility).
I do not believe that we should rely on some arbitrary meta-data when code analysis and revision history can determine which versions (indicated by semver tags; or failing that which revisions) satisfy every package's usage (your main, A & B) of the dependency's (C) API. At best I want the tool to tell me what's API compatible, based on actual knowledge of the code involved, and let me choose which to vendor. If the tool can't do it then I need to fall back to understanding more than any recorded version number range(s) can tell me anyway.
This is where I think Go is different and we should make more informed decisions about compatibility. We don't have to let human's play as much guesswork. In the end, when conflicts occur I'll need to update my code, the code of one or more deps, the diamond package or any combination there of regardless.
--
Of course that's not where the state of any tool is right now. Maybe I'm thinking too big and want something that's not realistic (although I think it is). Also, if version ranges "win out" I can still make my (totally mythical) ideal tool and just ignore them except as suggestions to the user for resolving a conflict.