There are two possible scenarios I can think of, and I'm not really sure how to handle both the best way.
In simpler case, my library somehow manage to handle that backward-incompatibility (and now became an adapter). So I ship an patch version because API of my library did not change, and previous version is now have some kind of a buggy behavior (relies on external API that does not exists any more). The problem here is that all already built programs, as well as ones that uses some kind of dependency locks are now broken and must update their dependencies. Well, I can say that that's not a my problem, but it bugs me a bit.
In more complex and more real case, my library can't abstract that backward-incompatibility and it leaks through it, so I have to change a public API of my library too. So, I ship a major version. The problem is that it breaks the whole point of SemVer, where the user suppose to have the freedom to decide where they want to have a major update or do not, because a previous major version supposed to work along with the new one. But it does not and can't be patched.
I understand that SemVer approach is not supposed to handle such cases. But I have no idea what is supposed to. Is there any approaches to such cases out there?