AlexKir,
1) Есть маленькая тонкость: "узлы" это лишь понятие среды, и не добавляют ни одного байта кода, в отличии от Hub и GetData. Появились они, исторически, позже, и оба варианта разветвителей живут вместе, прежде всего, в силу соображений совместимости.
2) Использование данных, передающихся через поток, экономит (как Вы могли заметить) коды, хотя, возможно, менее очевидно. Ну а приоритеты HiAsm по выбору направления приема данных описаны в справке HiAsm.chm/Основы/Вступление
3) Ваш самый первый вариант, безусловно, работоспособен. Никаких претензий. Просто делимся соображениями

4) Зато в Дельфях исключения перехватываются. И выброшены только проверки, перехватываемые FPU. Там полная корректность, за исключением одной тонкости, о которой скажу ниже.
Про характеристику "гнуснейший" рунтайма - согласен. Не солидно
Под FPC, на данный момент, мы не имеем портированного с KOL модуля ERR. Именно он обеспечивает фичу exception. Стандартные средства Дельфи просят для этого около 100К кода дополнительно, а KOL - 6. Есть разница, однако. Если средства перехвата в FPC (недавно появившиеся, как Вы сказали) такого же калибра, что и в Дельфях, то это проблема....
А дальше альтернатива: а) Если мы отказываемся от технологии exception, то надо добавлять, удаленную ранее систему проверок, и вариант Дельфи переводить на эту же технологию. б) Трудимся над внедрением технологии под FPC, и здесь обнаруживаем новые подводные камни.

Приемлем ли первый вариант Это реально, и цена не очень большая - 2-3К кода. Но проверками всех исключений мы никогда не закроем (исключение можно получить даже на сложении двух чисел). И получится, что HiAsm все-равно останется способен выдавать тот самый "гнуснейший" рунтайм, хоть и по-реже. Вот в блоках "элементарной" математики все проверки на месте, а получить "гнуснейший" рунтайм - запросто. И, вроде, только математические блоки так гадят репутации HiAsm. Коды остальных элементов вроде можно написать так, чтобы его не было....

А что со вторым вариантом Да все отлично, кроме двух незадач... Первая - еще не знаю, как это сделать под FPC. Но, думается, что это физически преодолимо, все-таки.
Вторая - исключения в ObjectPascal (т.е. и в Дельфях тоже) полностью игнорируют факт расхода динамической памяти "незаконченными" продпрограммами. В отличии от C++, где существуют списки необходимых для выполнения деструкторов. Видимо, связано с идеологической разницей в языках: в C++ вызов конструкторов/деструкторов производится автоматически, а в паскалях - ручками. Этим сейчас страдает FMP - существует безвозвратный (не такой уж большой, если один раз) расход памяти при ошибках в компиляции строки. В MP такого нет, но не надо кричать ура Там возможен вызов вычислительного процесса через верхнюю точку, а там в свою очередь возможны исключения (вспомните вышестоящую сентенцию об "элементарных" мат-элементах), которые честно перехватываются (:! вызывающим парсером - и чего будет с памятью, не ясно
Вобщем-то, проблему расхода памяти при исключениях в FMP персонально преодолеть можно - организовать ручками список необходимых деструкторов, который реализуется в обработчике исключений. Но остается вышеупомянутый вопрос вызова схемных блоков HiAsm через верхние точки элемента

===================================
Вобщем, застряло это как-то на фазе подобных философских размышлений, что не совсем хорошо, естественно..............