The whole "grab the latest semver compatible version" was designed for a reason, and just pinning to a specific version would bring us to a world where very different articles need to be written. Specifically, when there's a vulnerability in any dependency (a thing that happens much more often than a rogue OSS dev) the upgrade process would be a nightmare for everyone involved.

You have to chose one of the two evils; automatic bug/vulnerability fixes, or protection against rogue OSS devs you depend on. I'd say the former is an order of magnitude more common and important, and so the npm/JS world works this way.

I wonder if both are possible with a trust system where releases can be approved or signed by community members. This way we can have automatic semver updates for releases approved by people we trust.

Something like "I trust NPM so accept all releases that NPM has approved". Large companies could have their own internal approval keys etc.

It is really good, allowing for distributed reviews, not necessarily from the people authoring your dependencies. The OP suggests that if you -> A -> B, the package manager should only install versions of B vetted by A (or close); I think this doesn't scale well in practice (all the more so if the only way A can vet a new version of B is by doing a new release). Having the possibility to rely on other people to vet releases (possibly in your company) opens a lot of doors, such as the ability to not trust the author of A at all.