Personally I'd love to see RO5 'ported' back to the RiscPC/A7K, if only for environmental reasons - I don't like the idea of old machines being thrown out if they are fast enough to perform the desired task - sadly most machines are thrown out because software has become less efficient.
But I think our chances of seeing an OS that can run 26-bit only, 26-/32-bit neutral AND 32-bit only code are virtually nil. RO5 only runs apps that fall into the latter two categories.
Which means that if you upgraded your RiscPC to this theoretical RO5 you would lose the ability to use those apps which are still 26-bit, eg. Impression, Sibelius, Eureka, PipeDream plus (from our feedback @ Aemulor) many lesser-known but still frequently-used apps.
You would need something akin to Aemulor that would switch the StrongARM back into 26-bit mode in order to run the 26-bit-only module/app code and then wrap SWI calls etc so that they provide the old behaviour as per RO4, eg. flag preservation and undoing the API changes that have been
made in RO5...plus, callbacks from the OS to the 26-bit code would need wrapping so that the SA is switched back to 26-bit mode...
From experience I can tell you that this is no small amount of work.
For those of you who are wondering "why can't we just run RO5 + Aemulor" on our RiscPCs, Aemulor relies upon hardware features that're unique to the XScale processors...ie. not present on the StrongARM; it wouldn't be possible to emulate 26-bit code at the same speed in the StrongARM's 32-bit mode (at least, not without a radically better approach that I haven't yet thought of!
> Could the work done in Aemulor be used to allow current MT apps to run in a new PMT RISC OS?
Yes it could.... or, at least, it would help if your apps are 26-bit RO ARM code & your OS isn't ARM-based, in the sense that Aemulor provides a fair wodge of RO functionality but in portable code (C)...but, to be fair, even the latest x86 hardware can't run ARM code at speeds comparable with native hardware, with the current emulators anyway.
More directly, the problem with making a new PMT RISC OS has less to do with the apps, and more to do with the WindowManager, FileSwitch & other filing system modules plus, of course, the RISc OS kernel..... and then, after you've got that lot working, you run into 'trivial' stuff like system variables which, traditionally, have global scope and yet Obey$Dir - for example - will almost certainly cause things to break.
PS. If ever you run out of hope, remember some folks are idiots and do things for free!