Changing code under their nose risks breaking bunch of projects. We can also fix this by rather communicating, right? But if we CAN communicate... then we can go back to the previous option (telling them to update) as it becomes just as viable.
Communicating is always essential, and can't be avoided.
In multithreading this would be basically mutable shared state with no coordination. Every thread sees everything, and is free to mutate any of it at any point. Which as we all know is a best practice in multithreading /s
Semver provides just a few bits of information, not nearly enough to cover the whole gamut of shared and distributed responsibility.
The comparison with multithreading is not really valid, since monorepos typically linearize history.
I could have some comments on your "overlapping responsibilities" as well, but your description is too abstract and vague to address, so I'm pass on that. But you literally described the concept of library at one point. There's nothing overlapping about it.
1. A critical security/performance fix has no other recourse than breaking the interface compatibility of a library. Far more common scenario is this can be fixed in the implementation without BC breaks (otherwise systems like semver wouldn't make sense).
2. The person maintaining the library knows the codebases of 10 teams better than the those 10 teams, so that person can patch their projects better and faster than the actual teams.
As a library maintainer, you know the interface of your library. But that's merely the "how" on the other end of those 30 call sites. You don't know the "why". You can easily break their projects, despite your code compiles just fine. So that'd be reckless of an approach.
Also your multi-repo scenario is artificially contrived. No, you don't need conditional branching and all this nonsense.
In the common scenario, you just push a patch that maintains BC and tell the teams to update and that's it.
And if you do have BC breaks, then:
1. Push a major version with the BC breaks and the fix.
2. Push a patch version deprecating that release and telling developers to update.
That's it. You don't need all this nonsense you listed.