I'd like to point out a bit of an erronious assumption in this article. The two API's were never designed to have anything to do with each other. The reason that it's difficult for engineers to figure out the relationship between the two is that there isn't one, other than that they both run on top of the same underlying OS. Yes, there are a few cases where Cocoa uses underlying Carbon services; this is a natural outgrowth of the fact that Cocoa runs across many operating systems (e.g. Windows), where it uses the native services, so when you run an OPENSTEP app on Windows, it'll use Windows print dialogs, etc.
But back to the main point -- the two API's aren't layered, and there is no master plan to combine the two. Cocoa provides all of the low-level functions that Carbon does, and more. They're just two completely different programming models, driven purely by the fact that many companies and developers would rather maintain an existing code base than face a rewrite.
Cocoa is how a tiny company has produced a better web browser than a huge team at MS -- Cocoa apps are easily 10x easier to write than Carbon. The only reason to use Carbon is because you've got too much legacy code to make a rewrite feasible, or you're too lazy to learn a new API. I predict that Cocoa developers will out-perform Carbon developers, and that aside from a few markets where there's no real competition, Cocoa-based products will beat Carbon in the marketplace, since the company will spend less money, produce higher quality software, and be more responsive to users' needs.