Btw

How Unix-compatible is signal-stuff in ixemul? AROS uses this to have Exec on top of Unix. Tasks are switched by poking sigcontext in Unix signal handler. Disable()/Enable() is blocking/unblocking Unix signals. Timers/VBlank is with SIGALRM.

Theoretically you could use similiar method to spawn one (or more) nested MorphOS (sand)boxes from MorphOS itself == MorphOS hosted on MorphOS. To run certain stuff in them. Possibly mem protected. Possibly in memory not reachable by normal MorphOS programs (> 2GB). Possibly on another core (if you add support to MorphOS itself to allow very "simple" tasks to run on another core = not doing things which are usually done in AOS and AOS apps that are not multi-core-compatible) ~ something like in powerpc.library era)).

MOS hosted on MOS would run as "simple" task (because of using ixemul.library). Stuff interacting with "host MOS" would maybe run in helper tasks. Like gfx driver. Or file/io for emulated file handler.

"simple": more or less only shuffling memory around and not using much else from host MOS beside msg functions and ixemul stuff required to hack "Exec on top of Unix" together.

Of course you could do this also without ixemul. But in Unix, signal-handler-context-poking is more or less some publicly documented feature, while directly doing such things in Exec requires poking private Task structs where context is store and theoretically since this is private the struct or place may even change without notice.