Да! серьёздно разраслась тема, и правда уже пора писать техзадание, даже на основе того, что здесь уже выложено.

Коментарии по ходу чтения:

1. Предложеная Vitamin'ом схема разделения памяти - хороша тем, что позволяет унифицировать все процессы - они хранятся в 16 кб страничках, как аласм. Кдинственное в ней в сегменте между #8000 и #c000 нужно давать возможность размещать как разделяемые несколькими потоками данные быстрого доступа, так и часть кода для быстрой обработки данных лежащих вне страницы с основным кодом (иначе я себе просто не представляю как делать те же текстовые редакторы или асемблер - они же тормозить будут)

2. Споры по поводу INT vs NMI считаю неконструктивным поскольку и то и другое можно реализовать и выбирать при помощи настроек системы. У кого есть MNI каждую милисекунду - настраивает на работу с NMI, у кого нет - на работу через INT. Что качается периода вызова, тоже не вижу проблем, можно так же настраивать период квантования для правильного учёта процессорного времени (для INT 1/50 секунды, для NMI - уж как реализована аппаратная часть). Разумеется при загрузке и инициализации сначала все работать должно на INT а то и вообще с запрещёнными прерываниями, а уж потом, если есть соответствующие настройки - включает через порты фишку с NMI раз в 1 милисекунду и разуется жизни форева. С INT будет вытесняющая многозадачность (di поставил и жрёшь ресурсы сколько влезет) а с NMI - вытесняющая, посколько прерывания немаскируемые.

3. По поводу Fork и разделяемого кода. Можно для библиотек ввести дескрипторы (2-4 байта - систему выдачи уникальных идентификаторов вроде GUID у мелкомягких), такие же дескрипторы использовать и для приложений, тогда можно будет при необходимости пользоваться чужим кодом вызываю его через дескрипторы. Так же, в случае fork, Vitamin верно предложил, по минимуму можно для нового потока, порождённого через fork, копировть только стек, ну ещё контексты (вроде DC в виндовз).

4. Замораживающая многозадачность уже реализована в QC и RC, а так же в ACE и Alasm но от этого никому легче не становиться, програм поддерживающих это практически нет, разве что выход в командер после прочтения текста в листалке, созданной с помощью TextMaker, да по всей видимости в продуктах AlCo.

Теперь по поводу необходимоси всего этого, если бы всё это было не нужно и неудобно, никто бы не заглядывался на писюки и амиги вот как там здорово можно несколько задач выполнять не делая сброс компьютера. Другое дело, что чтобы сделать дейстующий экземпляр чего-то такого придётся неплохо поломать голову и немало времени потратить на реализацию, особенно, если будет хорошо поддержана совместимость со старыми программами, хотябы под TR-DOS.
Без приложений ОС не нужна никому кроме как разработчиков, которые семореализовались, написав её. А запускать программы пользователю фиолетово, хоть через TR-DOS+boot/командер хоть через супер-пупер навороченую ОС с многозадачностями. С точки зрения программиста, в ОС для спека особенно важно, чтобы ограничений на оптимозацию работы программ под неё было минимум. Но и эта проблема, я думаю, не слишком тяжела, если всё правильно спроектировать и разработать механизм быстрого доступа к данным и коду, как собственной программы, так и ядра системы(один из вариантов решения этой задачи я уже предлагал в пункте 1).