@Daedalus
Surely it's much simpler than that though.
When you write a program using MUI, you need to reference the MUI header file(s). As long as the Zune header files are named differently, it doesn't matter that the functions contained within them are named the same as their MUI equivalents, as the compiler will link to the functions you intended to use.
Perhaps the view that MUI and Zune cannot co-exist is being put forward by non-coders?
While you could prepare a Zune that'd run alongside MUI on MorphOS, you would indeed need to compile all apps for it with modified headers so that all classes would use a different name (a prefix, like some "non-coder" here suggested could work, but not in the compiler but in headers obviously
This of course means that you cannot compile a single binary that'd run using Zune or MUI depending on what's installed. You cannot replace MUI with Zune on MorphOS because MorphOS (for instance, intuition.library) relies on its internals heavily (structures, private methods, attributes, etc). Since those methods are, well, private, they wouldn't be available in Zune. And what would be the point of having two libraries alongside doing virtually the same (but Zune doing obviously less than MUI 4.0 and being poorly integrated)?
