My guess is that if always-lazy cells (as we understand them now) sometimes should propagate and sometimes should not (ie, if we cannot come up with One Right Answer) then it should be a new attribute, in which case it should be two new attributes (lazy-calculate and lazy-propagate) replacing lazy. That certainly would give developers all the options in the world (I really do not think a third "lazy-observe" attribute would be appropriate given the meaning of "observe" <g>). But...

...I really hate introducing things without Use Cases to focus the mind. To a degree we are compromising the data integrity by letting values go out of synch with each other. Yes, they pop back into synch when read, but what about observers? If A is eager and depends on B and A has an observer that really really wants to stay on top of reality.... at this point the developer is responsible for keeping the world in order.

That is not necessarily a bad thing, unless it is unnecessary and can be handled automatically with more effort on the design side.

Jes thinkin out loud.

kt