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

Которая в HiAsm выражается примерно так: при проектировании схемы следует полностью игнорировать его содержимое, и относиться к нему как к элементу.
Как будто его написал другой человек, и он может использоваться в нескольких экземплярах.

И именно таким образом следует распределять ф-и по мультиэлементам.
И только после этого станет возможным собирать схемы неограниченной сложности.
Опять же давно уже (по результатам - без пользы) приводил пример: в схеме ElementsDelphiExampleDrawFifteens.sha я могу заменить мультик <Заполнение матрицы случайными числами> на свой, с генерацией ТОЛЬКО собираемых комбинаций. И у меня нет никаких сомнений, что если мультик работает правильно (в другой тестовой схеме), то и все схема БУДЕТ работать правильно. Именно это называется устойчивостью, каковым оно на самом деле сегодня и является.

Более того, это не мы придумали - в этом смысл ООП. Или по другому: Объектно Ориентированный Дизайн - есть и такой термин.

И ваши предложение отказаться от "матрешковости" - это отказаться от принципов ООП.



Я показал фичу для абсолютно всех элементов - измени код в одном, изменится функционирование всех экземпляров этого элемента.



Я не хуже Вас разбираюсь во времени.
А еще мне известен самый главный принцип экономии времени: сначала ДУМАТЬ, а уже потом делать.