Модули реализуются в виде классов. Ядро является модулем, так как требуются для него особенности модуля. Конфигурация в файле конфигурации, так как у многих уже наметан глаз на файлы с названиями config. Если конфиг засунуть в index, то это не добавит ясности, так как смешается с логикой. Конфигом определяются директории модулей ядра (движка) и модулей проекта. Это конфигурация не того и не другого, это конфиг для запуска движка. Там далее каждый модуль позаботится уже о своих настройках сам, в том числе и ядро (правда у ядра нет настроек). Кроме того, никакого значения для архитектуры нет, где находится конфигурация.

Единственная мелкая проблемка, с которой соглашусь – малая информативность файла index.php. Но это незначительная мелочь ради унификации всей логики системы.

Модули могут общаться так, как это требуется для решения задач. Напрямую, через события, через другие отношения. Ядро не навязывает архитектуру этих взаимоотношений, а создаёт условия для их удобного применения.

По-поводу «мы не должны конфигурировать ядро, редактируя ядро», в моем варианте файл ядра не редактируется, а изменяются свойства проекта (это данные!), которые автоматом определяются в файле ядра. Но это уже детали.

По-поводу «ясности» и «изучения часами кода», то это мне видится надуманной проблемой. Не вижу проблемы просмотреть алгоритм в файле ядра и сразу понять логику отображения страницы, когда там есть нормальные комментарии (это конечно в идеале так должно быть). В вашей текущей реализации в файле index.php всего пара подключений и вызов — как раз это и не вносит ясности и не объясняет алгоритм (работу). Единственное что ясно, это что чтобы понять систему надо изучать вглубь другие файлы, классы и т.д. Получается что у вас почти пустой файл ни о чем не говорящий. А значит это нагромождение.

Понятно, что вы пытаетесь реализовать унификацию и как стремление это конечно правильно. Просто речь идет о форме реализации этой унификации. Можно сделать это на уровне стандарта оформления исходных кодов модулей и всё, без необходимости создания контроллера (функции централизации обмена данными между модулями). Я за то, чтобы модули общались между собой НАПРЯМУЮ, миную какой-либо контроллер. Это значительно упрощает логику архитектуры системы. Если вы найдете аргументы против такого подхода, с удовольствием ознакомлюсь с ними.

Обоснование всему унификация и ясность.

Точно могу сказать, что в вашей схеме я полностью согласен с человечком, стрелочкой «запрос-ответ», и файлом index.php =) Хотя если быть дальновиднее, то вызов index.php должен осуществляться через файл htaccess. Еще начальную инициализацию config.php я бы включил как часть index.php и заменил на простое получение свойств проекта (его настроек mysql, текущей темы оформления и т.д.).

В моём понимании ядро — это файл (index.php + htaccess), который относится к конкретному проекту (сайту) и реагирует на HTTP-запросы отображая страницу со включенными в неё сниппетами, с учетом текущей темы оформления и т.д., а также выдавая код ошибки если требуется. Вот собственно и всё. То есть ядро — это никакой не главный модуль и вообще не модуль. Это просто стартер содержащий линейный алгоритм, в процессе которого вызываются функции от базовых функциональностей (на то они и базовые). То есть блок engine в схеме вообще не нужен.

Я бы вам порекомендовал отмотать немного назад ваши рассуждения, и написать статью о планируемой функциональности системы (хотя бы базовой части, при этом все равно желательно в кратце описать перспективы расширения функциональностей).

Чтобы не быть голословным, приведу пример описания по методу от общего к частному:

1. Система «CMS»
. |__ Свойства
. . name — наименование системы
. . version — версия системы
. . …
1.1. Функциональность «Проекты»
. |__ Объект «Проект»
. . |__ Свойства
. . . id — идентификатор проекта (сайта)
. . . name — имя проекта
. . . uri — абсолютный URI проекта на сервере
. . . mysql_host — адрес сервера БД (host)
. . . mysql_username — логин пользователя БД (username)
. . . mysql_password — пароль пользователя БД (password)
. . . mysql_basename — имя БД (basename)
. . . mysql_prefix — префикс имен таблиц БД
. . . php_error_reporting — уровень вывода ошибкок PHP
. . . fg_log — режим ведения логов
. . . …
. . |__ Файлы
. . . robots.txt
. . |__ Функции
. . . create — создание проекта (сайта)
. . . select — получение свойств проекта
. . . update — обновление свойств проекта
. . . robots_read — получение текста файла robots.txt
. . . robots_write — сохранение текста файла robots.txt
. . . delete — удаление проекта
. . . …
. . |__ Графический интерфейс администрирования
. . . меню выбора текущего проекта
. . . пункт меню «Проекты»
. . . экран управление списком проектов
. . . экран редактирования свойств проекта
. . . …
1.1.1. Функциональность «Тема оформления»
. |__ Объект «Тема оформления»
. . |__ Свойства
. . . id — идентификатор темы оформления
. . . name — имя темы оформления
. . . …
. . |__ Файлы
. . . /files/ — директория общих файлов
. . . /favicon/ — директория файла иконки проекта
. . |__ Функции
. . . create
. . . set — назначение темы формления по умолчанию
. . . select
. . . update
. . . delete
. . . …
. . |__ Графический интерфейс администрирования
. . . …
1.1.2. Функциональность «Страницы»
…
1.1.3. …