A package manager has know way of knowing what a breaking change is though because that entirely depends on how your code interacts with other packaged code. Some are easy to pin down and define. Others are almost impossible because people write software and people are inconsistent, they aren't omniscient and they can't understand or foresee every consequence of every aspect of the code they write. Why is version pinning so prevalent? The proximal reason is that modern package managers uniformly fail to provide the sane default of "give me the latest compatible version, excluding breaking changes."
Is your argument that we should give up and use one specific version of each library/package, and manually update the library/package version every so often? I can get behind that for offline software, but for anything exposed to the internet, the possibility of missing security fixes makes me leery of a purely manual update process.
Security vulnerabilities are another topic entirely, although they certainly overlap. Any changes to external packages you use increase the risk to your code - whether you let tools automatically upgrade or do it manually. Exhibit A - left-pad. We're still far from being able to automatically "verify" software - whatever that means in any given situation. Proving / verifying software has been a research topic since forever and still is. We do have better tools now to help with those decisions and hopefully they'll continue to improve in the future too. Whether that's semantic versioning. property based tests, dependent types and refinement types, automatic distribution, build and test tools,... the list goes on. the possibility of missing security fixes makes me leery of a purely manual update process.
Like @Wintermute, I'm struggling to follow what you're trying to say. The "better tools" you're referring to are precisely package managers. And they're useful precisely because they don't automate the decision entirely (leaving humans disempowered) but because they "help with those decisions" as you put it. So it's unclear to me where we disagree. Let me try to knock off a few things I'm not saying, just in case they weren't clear before: a) I'm not saying we should be deploying software to production by wantonly installing whatever the latest version of our dependencies happen to be. Things like Gemfile.lock in the Ruby/Bundler world are a good idea, and my post isn't about them at all. b) I'm not saying we should be upgrading our dependencies en masse and immediately running `git commit` without testing that the upgrade actually worked. Upgrading dependencies will and should always be a manual process. I just want it to be less of a bottomless time-sink. The two links I mention at the start of OP set all this background up. Perhaps I should have explicitly said people need to read/watch them before reading me. They're actually better posts written by better writers and programmers, so they're almost certain to be a better use of your time than my miniscule contribution (that I wrote without understanding Cargo, and so may well already be hopelessly wrong).