OberonCore

В OPAL входит Strings, а не STRINGS. Но это неважно - строки из него использовать нельзя. Возьмите WinDef.PSTR.
Предупреждая следующий вопрос , для линковки потребуется opengl32.lib.

а может проблема как раз в желании расширять?)) А про то что
расширение означает зависимость - не предупреждаем?))...

зы. Оберон нормальный язык но спроектированный из совершенно конкретных требований, для реализации конкретной
цели, без оглядки на совместимость и ВАШИ цели.
И поэтому многим сейчас он не подойдет.
Для переделывания Си-систем больше подошла бы некоторая
модернизированная Модула-4.
Вычищенная Модула-2, этакий Оберон-1, БЕЗ ООП.

зызы. Лучше бы Роман не РОСОЙ занялся а нормальный простой компилятор сделали. Пока что РОСА выглядит просто старым добрым освоением денег - неясно зачем она.

На общее утверждение - общей фразой: за всё приходится платить...

А теперь конкретно по утверждению: слишком общее, даже трудно проверить его правильность/неправильность Зависимость чего от чего, в каких случаях?

Я вот вижу наоборот снятие некоторых зависимостей. Различных групп разработчиков друг от друга. Конкретного разработчика от многих деталей, которые будут возникать в будущем...

ну здрасте...))
зависимость порожденного класса от родителя конечно!
как следствие - fragile base class problem...
по русски - тяжело менять базовый класс если у него есть потомки.
ООП на самом деле означает зависимость от разработчиков в чистом виде.

а в итоге? пришлось усовершенствовать Оберон в КП и вводить
всякие неочевидные модификаторы типа abstract с помощью
которых из record просто по сути вырезается аналог definition модуля.
(record это на самом деле составная сущность, имеет статическую
компоненту дескриптор типа - похожую на некий личный модуль?,
и видимую извне саму record)
может было бы естественнее оставить код там где
все статическое лежит - в модулях? и не париться с ООП совсем?
не знаю... но мне не кажется что в Обероне так уж все досконально
продумано, есть еще неясности. конечно это мое личное мнение.

fragile base class возникает при наследовании реализации в первую очередь.
Про модификаторы ООП в КП Вы отмечаете верно, но только касательно их происхождения.
В итоге, как оно есть сейчас, образовались несколько конкретных и эффективных механизмов организации расширяемости. Это как раз ООП не в суррогатном виде, а в "расчленённом", раскиданном на отдельные средства (бедный Алан Кей, мы тут его детище "препарировали" ).