"My package foo can say, "I depend on bar and work with bar >1.2.3 <3.0.0" if I know that foo isn't impacted by any of the potential breakages in bar 2.0.0 or 3.0.0. That in turn lets my package be used in a greater number of version contexts without causing undo pain to my consumers."
If I'm following the conversation correctly with vgo, the idea is that if you've got one bit of code that speaks bar 2.0, and another bit of code that speaks the incompatible bar 3.0, they'll be able to coexist in a single executable. Both bars will be compiled in, and anything that uses each of them will be linked correctly. That's one of the reasons why the v1/v2/v3 in the URL is important, these really are different packages. The dependency solver isn't trying to solve for the entire program with a single version. The types won't be able to cross if the package hasn't made provisions for that, of course.
If I'm following the conversation correctly with vgo, the idea is that if you've got one bit of code that speaks bar 2.0, and another bit of code that speaks the incompatible bar 3.0, they'll be able to coexist in a single executable. Both bars will be compiled in, and anything that uses each of them will be linked correctly. That's one of the reasons why the v1/v2/v3 in the URL is important, these really are different packages. The dependency solver isn't trying to solve for the entire program with a single version. The types won't be able to cross if the package hasn't made provisions for that, of course.