I advocate for this approach and want to see it adopted everywhere. It is essentially a hybrid of the opt-in approach (pinning) and opt-out approach (floating), where you can get essential security updates while not having interface changes forced on you.

Semver is not enough. This week I spent the better part of an entire day hunting down an obscure bug that couldn't be replicated by someone else on the team. It was a new build environment, so it was unclear where the problem existed. The dependencies were pinned—but some of the dependencies' dependencies were floating (e.g., "^1.2.3"), and one of those dependencies introduced a subtle breaking change in a minor version. This could have been resolved much faster if the locked dependency list was checked in (poor practice in an inherited codebase), but the problem remains.

It's not surprising that Russ Cox has been thinking about this. Just like Go's explicit error handling forces the developer to consider every error condition, "imver" forces the interface designer to explicitly consider older versions, instead of letting versioning implicitly handle it. The result is, hopefully, a more thoughtful change management process.