MorphOS_86 would mean: a) something like Amithlon, binary compatible to 68k/PPC, runs x86-code slower than it should (due to wrong endians) b) something like AROS+JanusUAE, runs x86-code at full speed, but intregration with 68k/PPC apps is lacking
Nothing I'm gonna get my pants wet about ....
IMO before a CPU-switch is done there should be some sort of "QBox", read an envoirement that keeps API-similarity (not compabiltiy) to MUI and other often used ABox-APIs. Ambient and other tools should run inside this box by default, while maintaining somesort of intregration with the ABox-side.
This QBox would have to be designed with SMP and MP in mind, should be agnostic to endians and address-size (32 or 64 bit).
Once such a box is in place and major apps are ported one would have to think about filling the gaps created by apps left behind in the ABox.
Only if thats successfull one might consider a x86-port.
(pretty much what Apple did from OS9 to Tiger-x86)
