Ну тогда придется все-таки вернуться к началу
Казалось бы, простой ответ: делаешь "тривиального" наследника к любому элементу, который уже будет являться мультиком.
Ан - дулю. Почему спрашивается. Потому-что дом с крыши строим.

Вообще-то существуют три последовательные задачи: Создание элемента => Наследование => Объекто-указание
И решать их в иной последовательности - можно получить совсем не то, что надо
Я себе плохо представляю, как можно говорить о наследовании, не имея технологии создания элемента средствами HiAsm

Да и объектоуказание - прошу прощения, но описанное - это не совсем то, что надо, например мне, для решения задач.
Мне нужно для решения задач, как минимум -- менять поле Obj в Run-Time
У этого элемента должна быть не одна характеристика, а ДВЕ: св-во, именуемое классом элемента, и определяющее его внешний вид, и хэндл конкретного объекта данного класса, получаемый в Run-Time.

Грубо говоря: есть динамический мультик, и в нем создано под сотню экземпляров. Соответственно, есть сто разных хэндлов
И любой из них пользователь должен иметь право установить в процессе работы (а не компиляции) в элемент с одним и тем же внешним видом (вот он-то и опредяляется в Design-Time)
Все просто - метод THIObjLinker.hSelect, например.
Который непонятно как должен распознать качество хэндла. Непонятно как, потому-что начинаем строить с крыши, наверное

Еще более банально - два (три, четыре, пять...) разных по содержанию мультика, но с одинаковым интерфейсом. Как это решается - они оба (все - грубо говоря) являются наследниками "пустышки", у которой есть только точки, а в ObjLinker эта пустышка выставлена как св-во класса, и хэндлы этих мультиков (например!!! возможны и другие решения - прямой и видимый линк до оригинала) подаются на hSelect

Так мое мнение такое: для того, чтобы заниматься программированием - нужно именно ЭТО.
А чтобы сделать это - нужно решать 3-х ходовую шахматную задачу. Спорить не буду, решать одноходовые - быстрее. Только это другие задачи, а не те, которые нужны. Как мне кажется.