1. левые и нижние точки вполне могут существовать одновременно на всех экземплярах сразу.
2. любая верхняя или правая точка может быть только у одной копии (ссылки) элемента, при любом их колличестве (точки можно переключать как радиобутоны). либо указывать очерёдность выдаваемых событий как у хаба (для правых точек).
------------ Дoбавленo в 23.12:
между копиями хотелось бы перемещаться, методом перебора или выбирая из контекстного списка путь к нужной ссылке..
------------ Дoбавленo в 23.19:
с интерфейсными надо что-то подумать - все его ссылки не могут быть копиями, след-но должны отличаться например наличием у них (в отличии от самого элемента) некоего значка (как сейчас на ссылке например)..

а если я вызываю некий метод у одного ссылочного элемента, а его data точка находится у другого? Это некое нарушение общепринятой концепции.

Еще одна важная особенность:
Допустим есть кнопка, вы хотите чтоб событие onClick происходило в мультике, но здесь есть одно НО, в мултиэлементы не вставишь интерфейсные объекты, поэтому pointer-ссылка не должна заимствовать у родителя интерфейсные функции(не знаю как назвать по-другому...)
А на счет в какой последовательности вызывать события либо по отступу сверху(самый нижний - последний) либо свойство вроде Tab(порядок выделения элемента по кнопке tab)

да, согласен.

Хм... Попробую изменить традиции, и начать с конца

Вот два дня уже пытаюсь вкурить в проблемы генерации кода - не выходит не фига у меня
И думаю, что их просто нет. Делов-то - на "три строчки кода", прости господи

А кодогенерация ObjLinker не должна отличаться от мультика-Ex - аж ничем

для MultiElement-ов их нет и никто не утверждал обратного. Речь в топике с первого до пердпоследнего сообщения шла о простых элементах, контейнерами не являющихся.

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

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

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

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

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

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

понятно, как обычно каждый о своем

И что в итоге?

на данный момент такой: реализация указателей на простые элементы целесообразна только в пакетах на базе кодогенератора FTCG

нет - это не будет нарушением общепринятой концепции (и совместимости) до тех пор, пока юзер не решит воспользоваться благами элемента pointer. На мой взгляд это верх элегантности ( никакого вреда кроме пользы : ) ..