Drivers require the " low level hardware programming capacity" I was referring to. Yes ROL have undoubtedly done much good work on 32bitting and producing a product that is a bit more portable than what they originally received - but if the problem is producing drivers being a difficult and time consuming task then emulation may appear to be an *easier* route as Microsoft (or other hardware vendors) have handled all the driver stuff for you *and* the emulator vendor has produced a product that to all intents and purposes looks, feels and moves like a RISC PC.
I don't doubt that ROL *will* finish the OS for the A9 (as to when who knows) the issue is more would ROL ever take on another ARM native hardware project (in that I'd include porting Select to Iyonix) and I suspect unless someone dumped a suitcase full of cash on their desk I would think not.
It really is down to persuading people to part with money for something that doesn't already exist and then with limited resources trying to implement it. Doing that with "new" hardware requires more resource *up front* - it also can have unseen difficulties and can take a *long time* (Omega and A9 being cases in point). In comparison porting to a "known" platform (like an emulated one) is less "greedy" of these resources and makes it more feasible to satisfy delivery in a reasonable time. A9, unfortunately, was just a tad too different to be easily accomodated. You'll note that updates for RPC's and VARPC are more frequent and take less time to arrive.
As A9 becomes more of a "known" quantity to ROL it'll become like the RPC and VA and get more frequent updates I suspect. Problem is if the quote from Paul Middleton is accurate it very much sounds like they'll never put themselves through all that hassle again - and that the *relative* ease of supporting an emulated ARM environment will win out.
Future native hardware will, therefore, need OS support from elsewhere (i.e., independant developers updating the ROOL/Castle sources) rather than from ROL.