event(onStrCat, s1 & s2)[/code]содержали код с уже правильным аттрибутом 

Кто ставит этот аттрибут - понятно. 
В этой логике, если вспомнить мой первый пример, то Stream всегда должен возвращаться с аттрибутом Volatile - нет вопросов.

Кто же использует этот аттрибут... 
Валить все на бедного HUB-а - не правильно, вроде бы :roll:
Ну не виноватый он :!:
Получается, что использовать ДОЛЖЕН кто угодно по одному простому признаку:
[quote]Метод элемента вызывает более одного события (в т.ч. и верхние точки), и события после первого используют данные из потока.[/quote]
HUB под этот признак проходит
Но под него как раз проходит и StrCat из первого примера (а HUB-а там и нет).
Если с HUB-ом все просто - срабатывание этого критерия видно сразу и до компиляции, то с остальными - нет.

Это вообще, только CG может увидеть. 

Т.е., первое же "использование" кодов с аттрибутом Volatile должно привести изменению кода на "буферизированный" и автоматической вставке "кода буферизации" ДО кодов именно этого метода...







[size=-2]------ Добавлено в 13:05 [/size]
Вот чего я еще подумал.
Пока схема грубоватая конечно... А как ее сделать более точной, хотя бы в последствии :?:

[u]Пока в голову пришло такое[/u]:

Вместо аттрибута Volatile надо сделать список "точек достижения"
Если он пустой - нет проблем и с кодом
Элемент StrCat к коду, возвращаемому ф-ей Result аттачит список точек, которые "достают" до doSrtCat. А элемент FileStream - тех, которые "достают" до точки Stream.
Каждый элемент имеет для каждой точки свой список: правые и верхние - список левых и нижних точек, которые могут активизировать именно эту; левые и нижние - список правых и верхних других элементов, связанных по схеме.
Теоретически, первые списки - это схемно-независимая характеристика именно класса элемента, а для создания второго списка методы элементов можно вроде и не парсить
Но всей схемой прошелестеть придется... Но один раз, вроде... Хотя...

Если такие списки готовы, то к данным можно добавить именно "голобальный список точек достижения"
Далее - все просто: "конструкторы данных" из CG объединяют списки; а при реализации [b]event[/b] из этого же метода, где и "сконструировались" данные - делается вышеозначенная языковая буфферизация, если это событие для точки, которая есть в списке "достижения" для передаваемых данных. 
Хорошо бы еще различать сам факт использования передаваемых данных...

Кажется, что такое было бы уже по полной программе