OberonCore

Для этого проще ввести язык, нежели вводить различные соглашения. Да и не важно, вводим мы отдельный надъязык, или пользуемся различными соглашениями - компилятор всё равно будет учитывать дополнительные правила, не изложенные в Сообщении о языке, т.е. фактически мы изменим язык КП.

Ключ?

Я бы предложил обратный сценарий - по умолчанию все скрыто.
Для открытия интерфейса какого-то модуля наружу подсистемы нужно скопировать его sym-файл в отдельный каталог подсистемы, например, я уже предлагал - Face.

Илья Ермаков Это подойдёт для системных подсистем (мда...), дял остальных не шипко удобно. Да и каталог тогда уж Export назвать. А копировать руками?

Не начнётся "цепная реакция" "тянучки", чего надо будет переписать в этот каталог? :о)

Найдутся те, кто для "удобства" скопирует все sym-файлы в этот каталог.

Именно это я и имел в виду, когда спросил про "цепную реакцию"!
Конечно, "правильно проектировать" - далёкая, идеальная цель, а люди работают сейчас, здесь и - разныя по уровню подготовки. Нужна "линейка для бития по руцях", что бы это соглашение соблюдалось. Причём - на уровне языка. Соглашения (принятые законы) для того и служат, что бы быть постоянным предметом нарушения... :о)

Насколько я понял, чтобы инфа о неэкспортруемых типах была доступна kernel'у она должна храниться в бинарнике. Это никого не смущает.
Может тогда и внутри-подсистемные интерфейсы включать прямо в бинарник (в спец. раздел), тогда
1) загрузчик и компилятор будут знать о них всё что надо
2) вне подсистемы они невидимы
3) поскольку эти интерфейсы, по определению, зависят от реализации, то и их возможная аннуляция при изменении тоже логична
4) копировать в Face уже просто нечего.
Такая схема, кажется, должна быть столь же стойкой, как и внутреняя реализация одного модуля.

А ведь неплохой вариант!

Понял чем плох этот вариант. Компилятору ведь нужно явное указание какой экспорт "для своих", а какой "для всех".
Кажется в этой схеме не обойтись без "++" и "--" (т.е. явного изменения языка).