@Lev I have considered that. It looks to me like a functional reactive programming patterns where you create projections/behaviours that you can compose together. Ambient monads, such as the transaction demonstrated in the example should be modelled to contain the functors (the computations that are the projections/behaviours - i.e. the binds (:: T x T -> T) that let the data flow through a pipeline inside a context) --> http://stackoverflow.com/questions/3870088/a-monad-is-just-a-monoid-in-the-category-of-endofunctors-whats-the-problem.
The problem being C# then: there's no way to contain computations statically, like what you can achieve with monads. You can do it dynamically using disposable observables though. I belive more in F#'s computation workflows in this case, giving access to a CLR interface that your behaviours (projections producing value) need to implement, that are then fed back into F# and the projection framework.
Once a framework for producing, joining and consuming (reacting to) values h