Oberon space

Тут ведь есть и другой вопрос - какие радикальные преимущества даёт подход, непременно требующий более сложных инструментов?
Лично мне нравится, что язык позволяет использовать самые простые средства для создания транслятора, что, впрочем, не означает, что эти средства всегда должны использоваться.

Как я понимаю - проблема в наследовании, да?

Не только. Дело в раздельной трансляции.
Есть, к примеру, интерфейс модуля, являющегося первичным исходником, а не сгенерированным из модуля.
interface A {
    type S = struct {
        a int
    }
    proc Init(var s: S)
    proc Do(var s: S, i: int)
}
Есть возможное воплощение этого интерфейса
module A {
    type S = struct {
        a: int
        b: [16] char
        s: *S
    }
    proc Init(var s: S) {
        ...
    }
    proc Do(var s: S, i: int) {
       ...
    }
}
Есть пользователь модуля A, которому передают интерфейс, а не сам модуль, так как именно интерфейс первичен.
module B {
     import A;

     proc Go {
         var s: [22] A.S
         var a: int
         for i = 0 .. last(s) {
              A.Init(s[i])
              A.Do(s[i], i)
              a = s[i].a
         }
     }
}
Как, имея только интерфейс A, транслятору собрать модуль B с эффективным размещением локального массива s из элементов структур S неизвестного размера.

Вот эта разница в модулях может быть реализована инструментами без изменения языка. Если же речь именно об удобстве пользователя, то тоже нет никаких технических проблем - это именно интерфейс уведомительного характера, и мелькающие то здесь, то там DEFINITION говорят о том, что, по крайней мере, для некоторых реализаций Оберона она воплощена, хотя, может, и не полностью.

Можно ещё ускорить с опцией -C ltoВозможно, из-за того, что 0..arr.len()является синтаксическим сахаром для
std::ops::Range {start: 0, end: arr.len()}

Поскольку речь идёт о сравнении с Си, то всё не совсем так по многим пунктам.

У Rust достаточно зрелый frontend, а backend, в котором и сосредоточен наибольший потенциал для проблем - это ещё более зрелый LLVM. В то же время компиляторы Си для микроконтроллеров, даже сделанными на основе GCC, часто грешат ошибками, но их всё равно задействуют в серьёзных вещах, например, для контроля Li-ion аккумулятора, который вообще-то и загореться может.

"Зрелые" и стандартные библиотеки для Си в системах для надёжного применения применять просто нельзя, так как они не соответствуют требованиям надёжности и защищённости.

Отсутствие статического анализа - это плохо, но немалая часть вещей, которые в Си находятся статическим анализом в Расте решены на уровне языка и компилятора. Heartbleed не был выявлен ни одним статическим анализатором, а вызван он был, насколько мне известно, переполнением буфера. Комментарий от одного из создателей статического анализатора - http://www.opennet.ru/openforum/vsluhforumID3/109478.html#10.

Системы автоматического доказательства корректности - это тяжёлая артилерия и применяется редко. Для Си его использование изрядно подпорчено наличием в языке препроцессора.

MISRA C, с одной стороны, давно вышла за рамки mission critical, так как является авторитетным сборником здравого смысла, и с исключениями некоторых правил используется весьма широко, с другой стороны, далеко не всегда MISRA C применяется в полной мере там, где это нужно.

Исходя из такого понимания, можно сказать, что абзац не устарел, так как в нём не навязывается ни Модула ни Ада, а просто приводятся как пример более удачных языков для надёжных программ, к тому же с оговоркой на их доступность для используемой платформы. Отсутствие специалистов по языку можно рассматривать как недоступность языка.
Сечас абзац можно было бы освежить примерами новых языков, например, Rust.

2) См. стандарт MISRA по этому поводу (думаю что это такое все знают):

Мне особенно нравилась редакция 1998 года:

Nonetheless, it should be recognised that there are other languages available which are in general better suited to safety-related systems, having (for example) fewer insecurities and better type checking. Examples of languages generally recognised to be more suitable than C are Ada and Modula 2. If such languages could be available for a proposed system then their use should be seriously considered in preference to C.

"\n" не преобразовывается потому что в обероновских строках не предусмотрены специальные символы. Нужно же было уложиться в 16 страниц

Что характерно, в C++ рекомендуют использовать std::endl, а "\n" считают устаревшей частью C. Вообще, надо сказать, что интерпретация спецсимволов - вещь очень платформоспецифичная и в учебном проекте совершенна не нужна (да, 16-17-страничный Оберон - это учебный проект)