> -- Rifat писал(а):
> Удивительно, но я сам недавно думал над этими проблемами (видимо многие идеи витают в воздухе и считываются из ноосферы  ...3) Лично я считаю, что расположение модулей в системе должно быть не одноуровневым и не двухуровневым, а многоуровневым, как дерево (аналогия с методами сверху вниз и снизу вверх). Можно привести аналогию с языком Oberon-07 (и другими Oberon-нами), где разрешены вложенные подпрограммы. В Oberon-07 есть правило, что вложенная подпрограмма может обращаться к своим локальным переменным или же к переменным глобального уровня. Думаю, что что-то типа этого правила можно ввести и для модулей, что модули внутри какой-то папки (подсистемы) могут обращаться к модулям глобального уровня, своего уровня и своего дочернего уровня (но не к подмодулям дочернего уровня).
Нечто похожее есть у языка Ада, но там довольно сложная реализация. И вот это отталкивает от многоуровневой системы.

> -- Цитата:
> Также нужно продумать то, как легко можно переключаться между вариантами реализации. Думаю, что можно создать один модуль интерфейса, который в IMPORT подключает один из вариантов модуля реализации. Таким образом, можно будет легко менять вариант реализации. Списки модулей, которые надо включить для сборки проекта должны включаться внутрь каждой подсистемы, чтобы на верхнем уровне указывать только включаемые подсистемы, а их списки подмодулей подключатся автоматически.Пока это еще не завершенная идея, возможно, что-то здесь не совсем хорошо, надо еще думать над этим.
То же размышлял над этим. И тут думаю есть простое решение - механизм "псевдонимов" модулей.
Совсем не обязательно вводить модули заглушки, а можно просто "снаружи" указывать что "МодульА" можно загружать под именем "МодульБ".