Alastair, I'm fairly under the weather today, so probably won't be able to reply to any more of your email until tomorrow (with luck). However, I do feel it necessary to correct you on one important aspect:

Green, Alastair J. wrote:

That is simply not true (ignoring the checking aspect, because that is orthogonal). Although the specification says nothing about reverse context flow, it does not preclude it and several implementations take/took advantage of the fact for precisely that reason. For example, in several places the OTS specification simply talks about propagating the context between "execution environments" and makes no indication of direction, whereas in others it does talk about "requests". It is fair to say that this is a deliberate "oversight" that dates back to the 1.0 version of the specification - I remember being involved in some fairly active discussion around this topic on the TC back in the early 1990's. I also seem to recall that at the time, Transarc and BEA were definite proponents of this requirement because of their existing implementation requirements. They also used it for low-cost interposition: subordinate coordinators were created upon request inflow and not registered with the parent until the response was received - the information about them was sent within a back context. Fairly obviously because it isn't mandated (or even fully specified), it affects interoperability in the OTS, so those vendors would only do it when they were sure about the capabilities of both endpoints, but that's a problem for the OTS - not a problem for the concept.

A little bit of further historical information that acts as another proof point. When we built the first distributed object transaction system in C++ back in 1986, we did precisely the same thing. This predated OTS, so we obviously had the freedom to ignore interoperability requirements (we were interoperable with ourselves, which was good enough for our users).

Mark.