I wouldn't expect the siblings to be guaranteed to receive it (since  
clearly you can't guarantee that they all do, since some may have  
already been evaluated, or may be being evaluated at the same time),  
but I wouldn't expect them to be guaranteed to *not* receive it.

Since the yaws_arg is being re-vamped anyway, maybe this should be  
carried around on the yaws_arg. A simple plist is probably fine for  
it. Then as the yaws_arg is returned changed it can be passed through  
changed. Then make all subcomponents pass the yaws_arg implicitly: so  
instead of {ewc,controller,func,[A,Foo]} calling func(A,Foo), make  
{ewc,controller,func,[Foo]]} call fun(A,Foo). That way you're not  
passing a stale yaws_arg accidentally. This is of course a backwards-
breaking change, but not a difficult one to fix, since all of the  
erlyweb code that I've seen and written passes it to the sub-
components anyway (even if it's not necessarily used).

Otherwise, you end up all of the components doing something like this:

show(A,Foo)
   NewA=yaws_arg:add_meta(A,[{title,get_the_title()}]),

   {return_with_meta,[{ewc,func,[NewA,Foo]}],
                     NewA}.

(once again, with better names than return_with_meta and add_meta)  
The worry here is that the subcomponents have to be called with NewA  
instead of A, which seems ripe for forgetting to me (especially if  
the yaws_arg some some validation before it passes it on; you could  
pass invalid data to sub-components this way).

I haven't looked at the contents of the yaws_arg, but if it's tagged  
with a type, then you could just do this:

show(A,Foo)
   [_New_yaws_arg=yaws_arg:add_property(A,[{title,get_the_title()}]),
    {ewc,func,[Foo]}].

Since erlyweb already knows to check the returned list for {ewc} and  
whatnot, it could just check for a new yaws_arg and start using that  
one. The problem there is that it forces {ewc}s to be processed  
serially (since what do you do when you get two conflicting  
yaws_args?), which my erlyweb does not (and given your blog post on a  
potential {concurrent,[{ewc,...}]}, I suspect this won't be a  
guarantee forever). Another idea is to just add another return value  
from controller functions:

show(A,Foo)
   [{add_property,{title,get_the_title()}},
    {add_property,{time_to_live,two_weeks()}}
    {ewc,controller,func,[Foo]},
    {ewc,controller,fun2,[yaws_arg:get_property(cookies)]].

(this was has my implicit-passing of yaws_args, but it's not  
necessary; not doing so does preclude children retrieving properties  
from parents, but if they need that they should pass it as an  
argument anyway). That doesn't carry the assumption that they are  
processed serially. It prevents parents from getting to children's  
properties without using {phased,Ewcs,...}, but that's probably not a  
problem, and isn't very avoidable. (I think all of these options do,  
if they want to do post-processing of any kind).

Personally, I like the last option, but it looks like it would  
require quite a few changes to the way that the erlyweb:ewc/N  
functions work

Any other ideas? How does that last one look?