hzn>It's taken ROL perhaps 2+ years to get their 32bit OS to work to the extent it does on the A9.
If you're right in thinking that it is (to quote you) "no surprise to think that they [ROL] plan to load their full OS and use just the odd hardware driver module from the RISC OS 5 ROM" I for one would be horrified. ROL's OS knows *nothing* of Iyonix! The Iyonix is *so* different from the RPC or A9Home that to do what you appear to suggest would take ROL a year or two.... Also Castle's drivers and modules are written to work on the Iyonix with its HAL and kernel - how do you think they'd react to an RO4 derived 32bit kernel then (just look at the "fun" regarding the 32bit SCL issues on the A9 to see how a relatively small change can cause *real* problems for the principals and users respectively).
You correctly point out that "The problem perhaps arising is if things like Aemulor, Geminus etc. will run with Select on RISC OS 5.". I'd agree - but if there were such issues one would have to seriously question the value of using Select on the Iyonix in the first place.
The *logical* approach is for ROL to modify their Select modules (after all they have the sources to these) and get them to work with the underlying OS (RO5) whose API is well documented. The other issue (which no one has really tackled) is that if ROL don't do hardware - and therefore are unlikely to *add value* to any existing or new hardware features on Iyonix - and if Castle have to try to get complex low level code to work with any new hardware but working also with an OS they don't control I would think we'd wind up seeing real problems (e.g., delays and bugs with one side blaming the other - can't wait for that (not....)).
For all those reasons I seriously hope that ROL will consider *softloading* their Select modules on top of a *full* RO5 OS - as IMHO I believe it to be the least likely to cause end users (or even ROL themselves) problems.