Ну мысли по инерции продолжают катиться дальше (что свидетельствует о не полной управляемости мыслительным процессом )

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

Логически рассуждая, приходим к выводу, что НЕ ВЫЗЫВАТЬ пустой (или отсутствующий Init) может только код, сделанный кодогенератором. А это опять же ф-ия Create_hi<Name>.......

Все это состыковать все-таки можно, несколько большим напряжением (для кодогенератора).
[code:1]function Create_hi<Name>(Sender:THIMultiElementEx):THiEditMultiEx; begin
Result := TClass<Name>.Create(Sender.Control).Child;
Result.Parent := Sender;
Result.MainClass.Init; //Ура! Именно это может отсутствовать (если пустой Init)
end;[/code:1]
В статическом случае, у кодогенератора (в отличии от кодов мультика) есть возможность прописать конструктор типа inline:
[code:1] ........ OnCreate := Create_hi<Name>;
Child := TClass<Name>.Create(<Name>.Control).Child // впрочем, parent кодогенератору и так должен быть известен
Child.Parent := <Name>;
........[/code:1]И, как и раньше, дополнить Init конструируемого контейнера.
А в динамическом, только:
[code:1] ........ OnCreate := Create_<Name>;
........[/code:1]При этом в мультике: CreateInstance, SetStaticProc, DynamicCreate и SaticCreate перестают существовать, но нужно открыть доступ:
[code:1] property Child write FChild; property Control read FControl;
property OnCreate write FOnCreate;[/code:1]
ну и еще кое-какие назначительные исправления в кодах мультика из-за этого....