Ну тогда господа Z180... Там с Flat memory model проблем нету. Внутренние порты релоцируются, эту функцию может выполнять BootROM.
А по софту, касаемо компилятора...
Хорошая мысль однако. Думаю если ее развивать, то надо начать с некой стандартизации карты памяти. Придумывать новый формат исполняемых файлов и вводить понятие сегментов.
Рассмотрим стандартный ZX. Мы имеем:
16 K ROM
16 K экран (условно)
16 K - назовем это resident area
16 K - назовем это page area
Наш бинарный файл должен иметь возможность:
1. Иметь произвольную длину.
2. Иметь произвольное количество сегментов с длиной не более 16 кб.
3. Иметь понятие атрибута сегмента. Один из сегментов может иметь атрибут Resident - именно он попадает в 0x8000. Остальные сегменты могут грузиться в произвольные страницы с 0xC000.
Остается два сегмента: ROM и Screen.
Тут я отступлюсь от энтузиазма и предложу нессчастный ROM оставить наконец в покое. Попытки его заменить генерируют массу проблем. Не все в состоянии это сделать. ROMABLE-система хороша как опция, но не более.
Screen - куда интереснее. Нам известно, что экран ZX - это 6 кб. Остается еще 10 кб. Идеальное место для размещения того, что в рабочем варианте назовем ZX Runtime kernel. Ее основная функция - связывать между собой сегменты программы. Эдакое наноядро. Программиста не должно волновать реальное расположение сегментов в страницах. Страницы ведь абсолютно идентичны между собой. ZRK машиннозависима ибо ей придется знать о том, какие страницы есть у машины и как их переключать. Еще тут придется содержать в себе некоторые legacy-системные переменные SOS, которые изменяют свое значение по прерываниям (вероятно что-то можно релоцировать, изменив IY) и стек (по крайней мере начальный).
Тут нужно еще ввести понятие BFI - Binary file interpreter (для знакомых с UNIX - функциональный аналог ELF Interpreter). Его задача - загрузить бинарник, совместно с ZRK раскидать его по сегментам и создать таблицу связей - какой логический сегмент программы какой физической странице соответствует. Кстати нет разницы, собирать программу из одного или кучи файлов, так можно в нагрузку и load-time библиотеки реализовать, наподобие .dll в Windows и .so в Linux - нагрузочная стоимость будет нулевой. Далее BFI может спокойно запускать загруженный код и прекращать свое существование.
Из программы ZRK может быть вызван явным и неявным образом:
1. Неявно - при осуществлении межсегментного перехода (far call) из одного paged-сегмента в другой или же обращении из одного Paged-сегмента к данным, находящимся в другом Paged-сегменте (не рекомендуемая практика ибо тормоз хотя в некоторых случаях это можно принести в жертву простоте).
2. Явно - при необходимости обеспечить непосредственный доступ к данным в каком-либо из paged-сегментов. При этом просто происходит переключение страницы и все. Разумеется наиболее часто такие вызовы будут осуществляться из Resident Area.

На языке C это могло бы в принципе выглядеть так:

[code]
#pragma resident // Объявляем Resident segment

void main(void)
{
SetPage(__selectmode); // Устанавливаем сегмент, содержащий данные
memcpy(0x4000, initscreen, 6192); // Данные были картинкой
SelectGameMode(); // Это простой вызов - сегмент уже включен, компилятор следит за этим
}

#pragma paged("selectmode") // Именованный paged segment, символ __selectmode генерируется линкером из имени сегмента

char initscreen[] = {...}; // ну вы поняли - это данные картинки

void SelectGameMode(void)
{
char m;

m = getch();
switch (m) {
case 's':
StartGame();
break;
case 'j':
SetupJoystick(); // А вот это - пример FAR CALL. Компилятор сам должен позаботиться об установке нужной страницы и то же самое по возврату.
break;
case 'k':
SetupKeyboard();
break;
}
}

#pragma paged("setups") // Еще один paged-сегмент, в него мы вынесли все настройки

void SetupJoystick(void)
{
// Тут мы выбираем тип джойстика
}

void SetupKeyboard(void)
{
// Тут мы производим назначение клавиш
}

#pragma physicalpage(#07,"screen2") // А тут мы просто определили __screen2, который понадобится нам для того, чтобы использовать теневой экран.

Я думаю что если бы было желание, то можно было бы переработать IS-DOS под такое распределение памяти. IS-DOS - отличная система, но в ней заложена серьезная концептуальная ошибка - она попросту не рассчитана на использование страничной памяти приложениями. ОС должна занимать нижнюю память, а не верхнюю. При этом она должна быть модульной (в IS-DOS это есть, но модуль нельзя динамически выбросить из системы и запихать на его место то что мне нужно). А предлагаемая мной концепция вкупе с реализацией сборки программы из нескольких файлов на этапе загрузки (load-time-linking) позволит решить тонну проблем. Каждая программа при загрузке будет фактически собирать собственную ОС под себя (для этого головному модулю достаточно указать, что для работы ему например необходим драйвер для работы с диском, драйвер мышки и драйвер принтера. Если это графический редактор - можно запросить еще и GUI-оконную систему. Если эмулятор терминала - драйвер модема и текстовую консоль. Супер-мега-киллер-демо вообще обойдется без всего этого и сможет работать само по себе используя лишь переключалку страниц из ZRK.
К сожалению сюда не вписываются некоторые расширения диспетчера памяти (например возможность Profi менять окно проецирования с 0xC000 на 0x4000, но это придется принести в жертву стандартизации. Если оно и подлежит использованию, то только машиннозависимыми модулями для внутренних нужд.
А вот диспетчерам памяти II поколения (к коим я могу отнести только АТМ-Турбо с его возможностью переключать вообще всю память) можно как раз найти применение, связанное с многозадачностью. Внутри такой структуры можно выделять виртуальные машины, в которых будут работать различные программы. Единственным остается вопрос разделения экрана - это надо как-то проработать.
Такая схема может позволить обеспечить совместимость и с классическими SOS, TR-DOS и IS-DOS-приложениями.
С IS-DOS все просто, необходимо перетащить ZRK как можно выше по памяти (но не залезая за 0xC000 - там электронные диски всякие и прочая лабудень), написать эмулятор API RST#10 - и готово. То, что было ядром IS-DOS-48кб - в верхние страницы, обращение через ZRK (сорри любители RAM-дисков, на дворе XXI век, обзаводитесь винтами).
У TR-DOS еще хуже - как правило из ее приложений нет выхода. Собственно, в качестве простейшего варианта решения можно вспомнить Windows 95 с ее опцией "Запускать в режиме MS-DOS". При попытке запуска такой программы сначала вылезает предупреждение о том, что любую среду придется покинуть. При утвердительном ответе Windows просто выгружается, оставляя программу работать в чистом MS-DOS. Плюс еще - TR-DOS-программы с дозагрузками можно запускать только с TR-DOS-дискет.
Вот так, начал с концепции ПО следующего поколения, а закончил описанием прототипа концепции очередной ОС. Хотя судя по всему одно от другого не отделимо. Кстати а что если взять IS-DOS и переработать под этот принцип? Насколько я понимаю ее исходники доступны? Хотя конечно можно написать и прототип работающий поверх TR-DOS...