The technical aspects have been well-answered above, and—for books—Levin's three-volume new OS X book replaces the book that was mentioned above, and is a good resource.
Now consider this at a higher level...
Compatibility is something all users and developers want, as we're otherwise building apps on a shifting foundation of mud and sticks, and that gets tedious and expensive.
Conversely, rote rigidity is not desirable, however. We don't get updates and enhancements, or they're slower, or more complex.
As valuable as API and ABI compatibility is, rote compatibility means the platform is locked into older designs and older limits and older bugs, which can constrain or even prevent desirable changes, and increases the costs of current and future work.
More generally, removing the older and limited and insecure APIs and ABIs means the old code supporting all that can also be ripped out, and the bug reports around issues and exploits that might be present closed, and which means you're writing more code in your hypothetical replacement project to retrofit those older interfaces into the newer environment.
Using something else that you're probably familiar with (this based on your nick) as an example of the strategy that Apple follows here, transport layer security (TLS) is a wrapper that is intended to provide a range of different choices for a secure key exchange, for the encryption used, and the handshake itself. This design allows a range of choices that can be used, and allows newer and more secure choices to be made available, while also allowing older and insecure key exchanges, ciphers, and handshakes to be deprecated and eventually to be removed as and if necessary.
What happens with TLS is also what happens with APIs and ABIs within most any platform that is being actively updated, though not necessarily as "cleanly" as the TLS design. ABIs and APIs can need to be retired and replaced, though—to avoid churning apps and developers—that deprecation and retirement and (where applicable) replacement preferably happens at timeframes longer than the LTS for the platform, or longer. In the case of Apple, the 64-bit transition started with OS X 10.5 and 10.6; a while ago. The 64-bit transition also removed the Carbon APIs, which were deprecated at OS X 10.8. Among other older and 32-bit code.
Could you craft a completely compatible design, given sufficient time and money? Probably. But parts of it will—like older TLS versions—be insecure or busted or otherwise limited. And now your platform code is that much more complex and convoluted and unstable and limited. And that much more insecure. And can block some of the changes you might want to implement—such as a hypothetical ABI that previously specified an eight byte user-allocated buffer for a cryptographic hash being replaced with a now-secure cryptographic hash requiring sixteen or thirty-two bytes. Keeping that old ABI means you're inherently dragging around fodder for exploits. Or for your retrofit, now you're reimplementing the bug.
Even ill-used code has to be built and maintained and tested and secured.
The other wrinkle here is that all this app compatibility work and all this investment is intended for apps that aren't being maintained or invested by their vendors, or by users wishing to avoid purchasing newer versions of those apps. Or put differently, folks that aren't spending or aren't buying.
In short, the "can't be done" is pretty close. Not at a price and with a development schedule and with the inherent limitations to changes that most of us would be willing to pay. Boot a hypervisor guest on Intel platforms. Maybe boot an emulator and a guest (QEMU?) on Apple silicon. Or maybe update the apps once a decade, or purchase newer versions or alternatives of those same apps occasionally.
