ok, so I guess we're jumping ahead to the implementation roadmap discussion without waiting for the EAP6.1 spec then. Is that the same Jason who just got done telling me the JBossTS planning cycle is too far in advance of the AS planning cycle? :-)
If the AS has no preference either way, then I'm inclined to go with the tx branch interposition model rather than full interposition, on the basis that transaction branch lock sharing is a more intuitive and powerful model for users. Whist I think it's the right goal, it's undeniably more complex to implement than the full interposition model. However, rather than go with full interposition as a stopgap and then change over and waste that work, I'd prefer to look at how we can break down the branch interposition implementation into smaller pieces to deliver the functionality incrementally.
With an incremental approach we may even be able to put in place a partial solution for some of the more limited but common use cases in AS7.1, much less a later release. For example, I think it's feasible to extend the org.jboss.tm spi to support a subordinate tx type that exposes beforeCompletion for remote usage. JCA tx inflow does not offer that, but the TS impl under it already does, so we just need the ability to wire it through without tying the AS too closely to the TS implementation classes. That kind of conservative change should be possible on the existing maintenance branch without forking, as it's not going to impact compatibility. Unifying the way the AS and TS do node identity and putting in place the AS side management of the peer node id list that's needed for recovery can also be done up front to avoid later alteration to the domain model - not all the work is going to be on the TS code side.
Some of the more involved TS internal recovery changes may also make sense to do even before we know if the wider feature does make the cut when it comes to prioritizing work for the next release cycle. We could for example potentially enable recovery for multiple resources even in the broken JCA spec semantics, which is an outstanding customer request. It's been a low priority thus far as it's limited to one customer, albeit a large one. But if the work overlaps with wider tx inflow support then it's easier to justify the allocation of resources to it. As the new JCA integration spi is already in place (finally!) the remaining bits needed would likely be entirely arjuna internal, so again probably doesn't require a major version rev or fork on the TS code side.
Whilst getting at least some functionality out sooner rather than later is probably a good thing, one of my concerns on delivering this in staged releases, potentially including the current cycle, is the impact it will have on docs and QE. We'd need to clearly specify what scenarios are expected to work in each release we provide, in order to test correctly and manage user expectations thoroughly. We probably need an internal discussion with those teams to see what resource they have available in addition to seeing what dev resource we can shake loose for this by deprioritizing other things.