You don't need a monolithic repo to do that. Just pull in the library as a git submodule, and you control exactly which version (by git commit hash) of the library you use. And in a single commit, you can change that commit hash and change the code using the library, just as you could in a monolithic repo.
With subrepos, you -- the consumer -- are still stuck with either stagnation ("stability") or you need take on a bunch of refactors whenever you update the reference to upstream.
The producer in that case is obviously completely unaware of what you're doing so they cannot make decisions based on that fact. They may, for example, deprecate an API and provide no direct equivalent because they don't know anyone's relying on it. Then you suddenly have to come up with additional code to restore an equivalent API...
The subrepo approach is OK if you're tracking some external code. In that case it's comparable to semver but possibly better integrated with your build/tooling, you win something. But if it's internal to your organization, you're hacking around what a single repo could provide you.
This is exactly the opposite of what I was arguing for. In a monolithic repo, I can see and control what the consumers are doing. Your version is actually just a way to implement semver. (Or, possibly, to do something worse than semver; subrepos by themselves, provide no stability contract, so I have to think really hard about updating my subrepos.)
