it has a flaw in my application, which is the temporal aspect. In my application, there is no guarantee all of the transform nodes have been resolved before the orange node.
Your flaw is treating the observed y like it is only one node. There is a different y node for every modification.
In your first picture ? ispoints at line.point1.y
You want us to believe in the second picture that ? ispoints at rotate20.line.point1.y. But it's notit doesn't. It's still pointing at line.point1.y and whatever value that had before hasn't changed. rotate20.line.point1.y is a different y node, with a different value, that you didn't draw.
Yes the observer only cares about that y on the first point. But it must be pointing at the correct y. There is a new y for the first point for every modification. The last picture just shows two different ways to get the information about which y to look at.
Given that system, the simple solution is to update the observer when you make a new y.
What you've created here is a snapshot, command log, replay system. Databases use a similar system for recovery. With a snapshot of the database (in your case the original line), and a log of every command issued since the snapshot (in your case your rotate and translate nodes) you can recreate the DB (in your case the final line state).
Since your graph is a graph of dependencies, and your observer wants to observe the final line (even if only part of it) the original line and all modifications to that original line must be dependencies.