If both projects share a source control system, you can commit a change and update its downstream usages all at once, with no breakage even temporarily. However, this requires source control that scales company-wide. (Git doesn't qualify.)
This is precisely the problem that submodules solve, much maligned though they are. It's essentially a dependency problem, and we have good answers for those.
Edit: Also I am fairly certain that the kernal experiences these kinds of issues, and is the flagship user of Git.
Linus built a tool that suits his needs well but he's not working at the same scale.
Team A should be able to develop without having to consult Team B constantly. That means you have to be mature about deprecating things before you just remove them, but I think that's what the whole article is about.
Of course even if you have atomic source control commits, you don't have atomic deployment so there's still migration to take care of, but it works fine for in-process API's.