0) Комдив радует безмерно. Об идеи создании Оберон-процессора разговаривали с Денисом в прошлом году (был проездом в Москве после Дня Оберона). Я тогда много чего наговорил))
1) Повторю свою концепцию первородного греха языка программирования: процессор должен быть продолжением языка, а не язык -- надстройкой над процессором (строго говоря, я подтащил это у Вирта).
2) Должно быть две реализации проца (базовые): совсем простая (для совсем маленьких приложений, 80% потребностей) и широкопрофильная (для покрытия 95...97% потребностей). В любом случае широкопрофильный процессор должен оставаться простым, чтобы при необходимости наклепать хоть 256 ядер.
3) Инструкции для регистров внутри ядра  -- вполне стандартные. Битовые, сравнение, перемещение, базовые математические операции. Как показывает практика -- не надо много регистров, нужна независимость исполнения инструкций внутри регистров. Думаю, 4 штуки должно хватить всем (с). Что касается работы с памятью -- то явно загрузка/выгрузка, косвенная адресация через параметры команд ииндексная адресацияпо примеру Z80 (регистры HL, IX, IY) -- очень удобно для обработки массивов значений. Кроме того,обязательнонужно использовать модульную сегментацию (в интелях это сделано черезчур муторно двумя способами, что ещё со страничным механизмом ну просто источник попоболи). Модули, разумеется должны поддерживать секции интерфейсов (для релоктабельности), секции кода, секции неизменяемых данных, секции изменяемых данных, и (скорей всего), потребуются секции разделяемых данных). Также на аппаратном уровне я бы заложился под типизацию. Знаю, типизацию переваривает компилятор на этапе компиляции, но! Если код получен из ненадёжного источника -- доверять ему нельзя. Поэтому, в таком случае типизация будет очень кстати. Кроме того, контролируя импорт модуля SYSTEM --  можно предупреждать пользователя об опасном модуле (и при необходимости запоминать ответ пользователя на уровне ОС). Независимые стеки -- само собой + думаю будет полезным иметь аппаратный стек, скажем на 16 слов (фактически эрзац-кэш). Флаги обычные + например, текущая глубина вызова (возможно при каждом вызове -- своё значение, т. е. по сути организация аппаратного контекста -- полезно для организации аппаратной защиты в духе обнуление/переполнение стека, нарушение границ сегментов и всё такое).
3а) Должна быть поддержка множества уровней привилегии на уровне проца. Скажем, одного регистра хватит всем (с). Это позволит создавать уровень супервизора, использовать несколько операционных систем одновременно, разделять безопасно пользователей и их (или системные) процессы.
4) Транслятор должен: работать в режиме с привелегиями (признак -- импорт SYSTEM), должен позволять строить AST (и подписывать его при необходимости) или выдавать готовый бинарник (и также подписывать при необходимости). AST без подписи можно будет при недоверии к источнику трассировать в режиме интерпретатора, а если код явно безобидный -- динамически компилировать на целевой машине со всеми доступными оптимизациями (по сути, современная Java или .Net, WebAssembly). А всё остальное уже тысячу раз обговорено, и вытекает из необходимости строить AST, тут уже не интересно.

Прочитал 690 страниц из 1684 "Архитектура компьютеров". Задания не выполняю, лень. Но кое-что новое таки действительно получил.