Dilma, я к другому склоняюсь. Что менять чего-то придется - даже сомнений никаких
Может даже и "чего-то" - слишком мягко сказано

У нас сегодня за одну точку элемента отвечает ОДНА ф-ия в соответствующем файле.
Должно быть много
Какие конкретно и с какой функциональностью - не додумал еще
Идеология из букваря: Синтетически Управляемая Трансляция

Чтобы получить код соответствующий внешнему для элемента event-у, мы вызываем соответствующую ф-ию нашего скрипта (в букваре это называется получить один из синтетических атрибутов нетерминала - B.code, к примеру).
НО
Чтобы он это сделал для нас адекватно, ему могут понадобиться некие параметры. Ну, например, идут ли в потоке параметры, и в каком формате (чтобы нужные конверторы прилепить к примеру).
Ну правильно - мы худо-бедно их дает как аргумент ф-ии скрипта.
НО, чтобы мы их адекватно сделали, хорошо бы знать, а нужны ли они будут вообще: может у меня картинка, а там real просят. Или вообще ничего не подключено.

Как про такое букварь говорит
А он говорит: если тебе для получения синтетического атрибута Code нужен наследуемый атрибут Type - так посчитай его. Если для его подсчета нужен опять синтетический атрибут usedData - так посчитай его ДО Code.
Если... - ну и так далее

Ну, скажем прототипом этого (к примеру) usedData может быть встроенная ф-ия Linked
Но прямо скажем - она ведь не говорит нам всю правду
Даже если нам нужен только Linked
Вот, к примеру, HUB - какое же там linked для левого элемента, если справа все точки отключены.

Вывод: кроме ф-ии возвращающей атрибут Code, нам для той же точки нужна ф-ия, возвращающая атрибут Linked (ну или более общий случай - usedData)

Может (даже - скорее всего) при дальнейшем размышлении - еще какие-нибудь понадобятся...

---

В этом аспекте может существовать атрибутик, вычисление которого вовсе не делает программу ветки
Ну грубо говоря - мы не озадачивались посчитать атрибут Code, а делали анализ другого, более простого атрибута (при целевом Code он тоже понадобился бы)