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 refe

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.