in reviewing some of the patches lately, i was again bothered by the complexity of outstandingChanges used by PrepRP and FinalRP. Both threads touch that list and prepRP checks both the list and the datatree.
right now datatree has the committed changes, but if we make datatree store the pending changes, then it can be completely maintained by the prepRP. it would also mean that prepRP would execute all operations: both the read and write operations. it turns out that we never take advantage of the fact that datatree contains only committed operations.
in general, i think this would simplify the code, make finalRP go away, allow us to get rid of outstandingChanges and allow us to do all datatree manipulation in the prepRP.
there is a downside: currently order operations as we get them from the clients, which works with the above. we have occasionally talked about letting read operations short circuit the pipeline if there are no writes from the client issuing the read in the pipeline. short circuited requests would go straight to finalRP. if we implement the above, this optimization would be much harder to implement. (i don't see it as much of an issue since we don't have any plans to implement it currently.)