Dilma,
1)
Точно так же непонятно чем. В вышеприведенном примере четыре прямолинейных связи (2 горизонтальных: от onClick Button-ов к точкам 1 ссылок, и 2 вертикальных: от точек 2 ссылок к Text Edit-ов) восстановить можно однозначно. Так вот, утверждение состоит в том, что они БЫЛИ.

2) Местоположение RES-файла не очень предсказуемо. И это неправильно. При компиляции в режиме Ctrl+D он лежит в папке Compiler\, а не Elements\Code\ (надеюсь, я правильно понимаю термин "папка проекта"). Более того, после этой операции, первая компиляция другого проекта (он не в режиме Ctrl+D) берет предыдущий RES-файл (который лежит в папке Compiler), и правильная прога начинает просто неправильно работать. При второй компиляции - уже все нормально.

3)
Откройте мне, тупому, что такое указатель на на класс .
Локализацию в памяти имеют экземпляры класса и методы класса. Указателя на класс не бывает. По крайней мере, я до сих пор так думал. А в полях элемента MultiElementEx у нас уже лежит указатель на элемент EditMultiEx из текущего экземпляр класса (FChild), и на конструктор класса (FOnCreate - хитрым способом правда, но, как я понимаю, это лишь следствие хитромудрости Object Pascal). А в элементе EditMultiEx (с этой версии) есть указатель на экземпляр класса (MainClass), в котором этот элемент и находится.
Так каких указателей нам еще не хватает, и в чем открытая Америка-то
Обойтись обычным копированием можно и сейчас - это вопрос интерфейса, а не генерации кодов. Просто, иногда и копирование необходимо, например, чтобы всего лишь изменить пару связей.
Ну непосредственно и про "править". Целью исправлений было перевод теоретических рассуждений предыдущих постов, в проверенные факты.
Перевел, для меня это теперь проверенные факты. И у меня теперь есть инструмент для изучения источников неконтролируемого расхода памяти.


4)
Так что же, все-таки, будет казаться более логичным многим
Этот вопрос очень важен, хотя бы потому, что и в следующий раз тоже есть шанс сделать чего-то не из той оперы. Хотя это и будет казаться более логичным. Многим.....
Даже если Вы предпишите лежать определению класса (а содержимое мультика является определением класса с незапамятных времен) в другом файле, или просто в отдельном месте, то как Вы по-другому сделаете рекурсивную ссылку Расскажите - и я не буду "править", а буду поступать именно так, по-другому.
Постановка вопроса, что рекурсивная ссылка - это буржуазная лженаука, НЕ УБЕЖДАЕТ. А других гарантированных методов рекурсии в HiAsm, я пока не слышал.
Но можно сказать и так:

Тогда, конечно, обсуждать нечего.

5)
Схему привести не могу по той причине, что сегодня схема в среде, и содержимое буфера обмена (как и сохраненного файла) это не одно и тоже.
Схема рекурсивного варианта сортировки лежит на форуме - два внутренних мультика заменил ссылками на новый внешний мультик. А этом новом внешнем мультике раположил ссылку на самый первый внешний мультик и соединил связями.
Что "лазание" по таким вложениям приводят к катастрофе я знал заранее, поэтому не лазил без необходимости, а откомпилировал в режиме Ctrl+D. Исходил из того, что проблемы среды и проблемы генерации кодов - это разные проблемы. Далее, по вышеописанному:

Просто теперь я знаю как с этой бедой справляться: включения юнитов вложенных мультиков перенес в раздел implementation. Например так:
[code:1]unit hiMultiElementEx_4B5FDF4;
interface

uses kol,Share,Messages,hiEditMultiEx,hiMultiElementEx{,hiMultiElementEx_4B6BEE4}; //отсюда убрал,

type
TClassMultiElementEx_4B5FDF4 = class
private
EditMultiEx_4B5FED0:THIEditMultiEx;
MultiElementEx_4B69E90:THIMultiElementEx;
public
Child:THIEditMultiEx;

constructor Create;
destructor Destroy; override;
end;

TMainClass = object
function Create(Control:PControl):THiEditMultiEx;
end;

var _Create_hiMultiElementEx_4B5FDF4:TMainClass;
implementation
uses hiMultiElementEx_4B6BEE4; //а сюда вставил
.............................
[/code:1]
И так в обоих файлах. Хотя, для размыкания кольца, достаточно было в одном. И от того, что я это проверил, это перестало быть теорией.
Вот и все