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




[size=-2]------ Добавлено в 16:42
Есть правда одна заморочка...
В смысле: не совсем полное достижение желаемой оптимальности.

В таком подходе мы не различаем последовательность происходящего.
В общем случае, ее может и не возможно различить, а вот в некоторых - она очевидна.

Скажем, про любимый нами HUB
Первая его выходная точка "недостижима" для входного кода, а вторая - "достижима" и честно его портит.
Пусть даже, для простоты, это второе событие и данных из потока не берет - например делает doClear какому-нибудь Memory, точка Value которого и начинает наш "зависимый" код

По нашей логике - HUB обязательно забуферизирует это дело.
Хоть и правильно все, но некий дискомфорт от того, что свой великий интеллект мы так до конца и не воплотили - остается

Аналогично в примерчике FileStream - поменяй местами точки Str1 и Str2, и никакой буферизации тоже не надо...
По той же причине: "достижимое" событие происходит после реализации кода...