in one sentence: os4 as a whole has become incompatible with amiga. which is actually the case for what i know. there is apparently less hassle to backport a good deal of aros software to genuine amiga system, not only because it guards the original concepts, it actually runs on 68k, because things like necessary functions are still register parametrized, library interface is interchangeable, hook syntax is apparently the same like the original one and last but not least aros has in comparison to the features it offers a reasonable memory footprint, comparable to original kickstarts.
what an irony..
AmigaOS4 still uses fundamentally the same system architecture (warts and everything) which you would find, for example, on page #7 of the 3rd edition RKM "Libraries". The philosophy of keeping the layer between the APIs and the underlying hardware (e.g. Exec, the CPU and memory) thin, so as to deliver the most power to the user, still applies, too.
Beyond that you're bound by the rules imposed by the development of the target hardware platform over the last 15+ years: ABIs, "glue" logic, off-the-shelf components and how the companies which cast all this into a mainboard you can buy and build a system from.
These hardware dependencies, and the new degrees of freedom they afford you are bound to change how the operating system goes about its business. This doesn't fundamentally restrict code written for that platform to be ported. What does make things more complicated is in how the dependencies through APIs evolve.
For example, how the dos.library in AmigaOS4 has evolved is a result of the "traditional" shortcomings of the dos.library design. These being global, public data structures with strange layout, cryptic labeling, simplistic protocols for avoiding clashes between concurrent access, and of course how file systems fit into this picture. It was hard to tell a "hack" from a "best practice" when interacting with dos.library and its data structures.
The dos.library in AmigaOS4 assumes more responsibilities than was the case in previous versions, in which file systems and client software was left to fend for themselves. The old way of doing things required a file system to implement an inane/insane number of operations, accessing crufty data structures according to very underdocumented rules, and this in turn led to stability issues. It was hard to write a robust file system, but poisonously easy to get it subtly wrong with dire consequences, for which it was extremely difficult to figure out what exactly caused them.
So, for example, dos.library now cares about how file change notifications work, how you would change the volume or device list after a medium change. This sounds like the most pedestrian thing to mention, but what goes on under the hood in dos.library V40 (and below) in these areas is a highly complex and error-prone process. Now there are well-documented and well-defined APIs for dealing with such tasks which are easier to use and far less error prone than what was possible before (new APIs and responsibilities, of course, required a more complex implementation, which the more powerful hardware platform certainly enabled).
Consequently, the crufty code which relied on the old methods was replaced, one component at a time, saving space and leading to a more stable and robust system. The Workbench, the shell commands, etc. were modified to use the new APIs.
You could backport such code, but you'd have to drop in replacements for the new API functions found in dos.library. The same relationship exists between the other "pillars" of the Amiga operating system, such as exec.library, graphics.library, intuition.library and the remainder of the operating system.
This is nothing new. It happened during the transition between Kickstart/Workbench 1.3 and 2.04. Even the Commodore developers themselves came to consider the tools (APIs, data structures, etc.) available in the 1.x days as very crude, compared to what 2.04 and beyond would deliver.
Portability of operating system code is not high on the list of things to keep an eye on when creating a new operating system release. If you find that AROS code makes for better backporting, it is likely because the APIs which the code to be ported relies upon, are extremely similar to what existed in 1994. This is not what AmigaOS4 was designed to deliver: it offers API compatibility, extending to data structures in the same way as Kickstart/Workbench 2.04 did to its precursor.
If you've read so far, congratulation! As you might have concluded by now, I do not subscribe to the idea that what makes an Amiga what it is would be strongly connected to how close it is to the operating system design or target hardware of AmigaOS 3.1.
