Dilma, до конца проработанной идеи у меня нет.
Но основная мысль такая:
1) На всяком языке могут быть библиотеки кодов. И, по- большому счету, есть альтернативы: включить исходники библиотек в проект, или производить связывание на уровне объектных кодов. Альтернативы и нам нужны
2) Скажем что-то типа такого: code_793
Т.е. у среды должна быть опциональная возможность пристегивать коды библиотеки к проекту.
Конечно было бы лучше, чтобы интеллектуально: только используемые мультики. Ничему не противоречит наличие в такой библиотеке IC. Если бы функциональность IC расширить до элемента - решило бы очень многие проблемы совместимости

Но это пока не более чем мысли....

Думаю эту проблему надо решать еще шире, раз уж повели речь о


а именно реализовать в рамках одной опции возможность подключить коды любых внешних компонент, не являющихся так скажем операционным ядром среды. Т.е. сейчас это User вкладка и любые пользовательские компоненты, не входящие в пакет. Есть над чем подумать.

PS: интересно, а в примере чья бага затерлась - кодогенератора или среды

С объектными кодами - это возможно и перебор
У каждого компилятора тут свой манер может оказаться...

А если совместимость на уровне бинарного кода, то это dll
И как отмечал коллега tsdima - тут все придумано, это COM-технология (с конструкторами, деструкторами, счетчиками ссылок, возвратом исключения...)
Там тоже начинается все понятно: dll-ка импортирует конструктор (с параметром-указателем на на такой же класс, что и возвращает, для вызова event-ов), а в интерфейс добавляет два наших любимых метода: doWork и GetVar (которые, правда, в отличии от наших любимых, должны возвращать HResult).
Осталось TData выполнить разумно. Чтобы не пристегнуть абсолютно все, что надо и не надо...

Это и есть те самые интерфейсные проблемы, о которых я долго и безуспешно беспокоился....

[size=-2]------ Добавлено в 08:26

Это в каком
Если в моем, то сразу понятно, что CodeGen не поддерживает создание класса без создания объекта. Не озадачивался этим никто.
Но сделать это - без проблем. Если принять за критерий НЕ создания объекта определенный класс контейнера. Впрочем, критерием может быть и "не видимость" контейнера. Для этого в CodeGen необходимо не пропускать такие, а анализировать на содержимое.

Но не пробовал еще...

Хотя можно и по-другому: создавать класс (pas-файл попросту) при первой же ссылке на него, независимо от того, родной это объект или линк. Ну и иметь, соответственно, список созданных классов, для того, что бы не создавать повторно.

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

Да пускай, по-моему....

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