Ano... takie mam wrażenie że takie jest podejście aby położyć się wreszcie i dobrze wyspać po latach dobrej roboty...
Za dużo jest problemów do rozwiązania "na raz" a jakkolwiek by ich nie rozwiązał to nie będzie to już to co było: praktycznie ten sam kernel działający tak samo w sensie API dla programów do tego stopnia że można było integrować emulowane programy 68K z systemem. Jakkolwiek by na to nie patrzeć port na maszyny Little Endian czy 64-bit (a jak robić drugie to i nie ma sensu robić drugiego) powoduje że takiej kompatybilności się nie uzyska. To samo jeśli chodzi o zmiany wymagane aby mieć obsługę wielu rdzeni jeśli to miałoby działać tak jak w innych systemach.
No chyba że... chyba że dałoby się (a powinno się technicznie dać!) zrobić tak że OS jest 32-bit i w Big Endian.
Dalej to robimy tak jak na kartach turbo czyli proces startuje na 32-bit na cpu0 normalnie a jak ma coś dużego do przeprocesowania to system uruchamia to na drugim kernelu który już obsługuje arm64 i cpu1, cpu2 i cpu3. Tam też powinno się dać na czas wykonania przełączać do woli endiana pomiędzy dużym a małym. Rozwiązanie iście godne systemu amigowego które co prawda nie sprawiło by że żadna z obecnych aplikacji działałaby jotę wydajniej ale już można by tak pisać nowe aplikacje aby pewne rzeczy wykonywać na dodatkowych rdzeniach a nawet używać optymalizacji napisanych stricte dla Little Endian.
Czy takie coś ma sens czy nie to zależy od tego jak procesor ma rozwiązany problem spójności cache - i o ile pomiędzy 68K i PPC które były innymi procesorami trzeba było to robić programowo to już niekoniecznie ten problem byśmy mieli na nowoczesnym ARMie. Dostępy do zasobów systemowych w najgorszym wypadku jeśli nie wymyśli się nic lepszego musiałyby odbywać się przez proces na cpu0. Na pewno każdy z wątków dla cpu1-3 działałby w nowym kernelu który ma swoją mapę pamięci z której ją przydziela ale jako że my nic nie ukrywamy można bez problemu operować na pamięci "niskiej" i tak np. program do rysowania mandelbrota albo inny ray tracer mógłby zadeklarować pamięć na bitmapę i stworzyć thready które by do tej pamięci do określonych jej części zapisywały wynik obliczeń. Taki program z perspektywy innych programów (o ile nie używają wyższych rdzeni) w ogóle praktyczne nie używałby czasu procesora. Tego typu optymalizacje można by wrzucać w różnych miejscach aby zmaksymalizować wykorzystanie procesora. Pisząc nowy program albo robiąc port jakiegoś programu który wymaga dużej wydajności tego typu mechanizmy można by wykorzystać. Też jeśli chodzi o BE i LE - ARM można sobie przełączać. Nikt tego za bardzo nie robi w np. Linuxie ale tzw. bare metal to i owszem. MorphOS to w zasadzie system bare metal...
Wg. mnie rozwiązania typu że coś tam "emulujemy" nie są do końca tym czego oczekujemy od takiego systemu jak MorphOS. Nawet ochrona pamięci... po co to komu, na co to komu? Tak samo raczej nikt nie chce systemu kompletnie bez aplikacji. Nie wszystko będzie się dało skompilować na nowo a tym bardziej jeśli będzie to wymagało większego effortu. Usunięcie/przepisanie wstawek assemblerowych to jedna sprawa a debugowanie problemów i przerabianie aplikacji z BE na LE to zupełnie inna. Podobnie zmiany w API wymagające aby grzebać w kodzie każdej jednej aplikacji. Emulator PPC potencjalnie można napisać i to samo M68K na to samo kopyto co obecnie emulacja M68K.
Oczywiście dalej mamy problem posiadania bazowego OSa na ARM co wymaga dużej ilości pracy aby się wydarzyło.
Tylko tutaj problemem nie jest tak naprawdę brak dokumentacji tylko sensowność takiej inwestycji. Czas to oczywiście inna sprawa ale jak będą chęci aby np. kupić wersję MOSa na RPi to pewnie i czas się znajdzie

Dokumentacja kuleje ale tak naprawdę wystarczy wybootować, ogarnąć na początek framebuffer, USB i LAN. Te można zgapić z Linuxa i projektów bare metal (np. Ultibo - tam nawet mają LAN i nawet akcelerację grafiki...). Bardziej bym tutaj widział RPi4 jako platforma developerska bo ten temat ma na obecną chwilę większy support ale docelowo przejście na bardziej sensowne RPi5 nie powinno już być takim dużym problemem. Zanim to by wszystko było gotowe do podstawowego używania (nawet bez jeszcze emulacji 68K/PPC) to to jak wybootować i zainicjalizować RPi5 zostanie gdzieś opisane.
Z tego też powodu kiedyś już pisałem o tym że Pi4 to najlepszy target dla MorphOSa. Temat został niejako zignorowany a same środowisko to się chyba zachłysnęło pomysłem odnośnie jakiegoś Rajzena co wg. mnie byłoby pomysłem całkowicie pozbawionym sensu i tylko odwracał uwagę od rzeczy rzeczy ważnych i istotnych - ARM może działać w BigEndian. Zresztą właśnie brak sensu jest powodem że takiego portu na horyzoncie nie widać. Za to port na RPi4 sens miał i to duży. Dalej ma choć w tym momencie docelowo już bardziej na Pi5 bo różnica wydajności jest po prostu:

. A znając życie to Pi6 będzie miał pewnie wydajność Core i5 6700/7600 (a nawet jak dorzucą rdzenióff to 8600) czyli ~2x lepsza wydajność jednego wątku i ogólnie szok i niedowierzanie i dumanie że szkoda że jednak nic nie zrobiono.