I don't know of any good books that specifically contrasts the advantages of the AmigaOS design with modern designs, unfortunately. A lot of these things won't have been spelled out in books at the time because it seemed obvious once you'd used an Amiga for a while.
Some of them certainly expect single-user. I think Linux etc. loses out quite a bit by not differentiating between single user (in terms of "person in front of the machine is most important, regardless of uid) and multi-user systems.
Some of it could be emulated by tweaking priorities. But others require a large change in how you think about applications. E.g. the widget ("gadget" in Amiga-speak) responsiveness largely comes from the OS threads carrying out updates of them. To do the same in an X app for example, you'd need your app to explicitly start a separate thread to forward events to your main thread, and have a mechanism for giving it higher priority. It's not that hard to do, but without libraries providing wrappers for it, it won't happen often.
Other things, like the assigns could be implemented easily enough with a filesystem driver. Coupled with namespaces you certainly can do this transparently in a multi-user system.
Memory protection helped reducing the cost of context switches, and certainly there has been a variety of sins carried out as a result of it being possible to pass data all over the place without paying much attention to it. But it's not that integral to the things that make AmigaOS unique.
With respect to ARM systems, AROS runs on ARM (and x86, PPC, m68k) and AROS is relatively close to parity with the lastest AmigaOS releases (including features from the 4.x series for PPC). I think at least one AROS distribution has images for Raspberry Pi for example. If nothing else it's a good place to get a feel for how some of it works.
Some of them certainly expect single-user. I think Linux etc. loses out quite a bit by not differentiating between single user (in terms of "person in front of the machine is most important, regardless of uid) and multi-user systems.
Some of it could be emulated by tweaking priorities. But others require a large change in how you think about applications. E.g. the widget ("gadget" in Amiga-speak) responsiveness largely comes from the OS threads carrying out updates of them. To do the same in an X app for example, you'd need your app to explicitly start a separate thread to forward events to your main thread, and have a mechanism for giving it higher priority. It's not that hard to do, but without libraries providing wrappers for it, it won't happen often.
Other things, like the assigns could be implemented easily enough with a filesystem driver. Coupled with namespaces you certainly can do this transparently in a multi-user system.
Memory protection helped reducing the cost of context switches, and certainly there has been a variety of sins carried out as a result of it being possible to pass data all over the place without paying much attention to it. But it's not that integral to the things that make AmigaOS unique.
With respect to ARM systems, AROS runs on ARM (and x86, PPC, m68k) and AROS is relatively close to parity with the lastest AmigaOS releases (including features from the 4.x series for PPC). I think at least one AROS distribution has images for Raspberry Pi for example. If nothing else it's a good place to get a feel for how some of it works.