Но смысл то создания дополнительного метода INIT в том, чтобы выполнить действия по проверкам на этапе компиляции, а не на момент исполнения
Было бы как раз правильнее совсем не включать в свой INIT-список INIT-метод вложенного (статического) контейнера, если тот оказался пустым. Как впрочем и для остальных элементов: не включать безусловно метод INIT для элемента, делая его пустым при необходимости, а включать только тот (и только если он есть), который стоит в правой части присваивания в INI-файле.
А сделать это уже однопроходным методом может (хотя точно утверждать не буду) и не получиться.

Посмотревши более внимательно, вижу, что не во всем был прав до этого. А именно:
1) Разборками со статикой занимается не конструктор мультика, а его property OnCreate. Ерунда, но из песни слова не выкинешь .
2) Нельзя безусловно вызывать Init сразу после вызова FOnCreate(), а следовательно и запихивать Init внуть Create_UnitName(). Можно только в динамическом случае, в статическом - нельзя. К сожалению
3) И все это при том, что по жизни программы это НЕЛЬЗЯ встречается один раз - при конструировании статического контейнера. Хоть перегружай эти действия (одинаковые, кстати, для всех контейнеров) на кодогенератор..... А в кодах элемента оставлять только действия для динамического случая.

Ну и ловушки на рекусию (статических :! контейнеров ставить надо.
Наверное