Сегодня одно из больших неудобств при работе с динамическими контейнерами заключается в том, что необходимо при обращение к методу конкретного экземпляра схемы вызывать ##select перед его вызовом. Что в этом плохого?
1) ну очевидно мы делаем совершенно лишнее действие, а значит заведомо усложняем нашу схему на пустом месте
2) такой подход без специальной защиты может давать сбои при обращении к объектам в паралельных потоках(сегодня эта проблема весьма призрачна, но тем не менее)

Каким образом от этого можно избавиться?
Видимо выход пока только один: разнести всю кухню по разным элементам. Например так:
- основной элемент контейнер, который на этапе конструирования содержит в себе шаблоны схем, а на этапе выполнения программы - массив конкретных экземпляров объектов
- элемент управления массивом - обычный элемент не контейнер с точками doAdd, doDelete, doClear, doFind(вместо doSelect), событиями onAdd, onDelete, onFind и т.д.
- элемент Объект. Это скорей всего новая сущность в среде, которая представляет из себя простой элемент, чьи точки определяются по связанному с ним шаблону из первого пункта. На этапе выполнения это ссылка на конкретный объект из массива экземпляров объектов по первому пункту.
Несколько поясню на аналогии с ЯВУ

Это первый возможный набросок, который тем не менее не решает некоторые проблемы:
1) что должно происходить при обращение к точкам шаблона из первого пункта? (у нас все таки не ЯВУ и никаких классов как таковых нет)
2) как указатель из массива объектов будет попадать в конкретный элемент пункта 3? (т.е. кто и как реализует присваивание указателя переменной m)

Очевидно так же то, что с такой организацией надо делать внутри контейнера элемент, который будет обладать точками onCreate и onDestroy

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