re: ( 1 ) Whilst the remote UserTransaction model is easy to implement, it's tricky to document. It behaves in an intuitive fashion only for a very limited, albeit common, set of use cases. For more complex scenarios its inherent limitations manifest in ways that can be confusing to users. The cost of this solution must be evaluated not just in terms of implementation time, but in documentation and ongoing support cost.
re: ( 2 ) JCA inflow was either designed for propagation to leaf nodes only, or incredibly badly thought out. Either way, the result is a model that simply isn't capable enough for a full distributed transaction solution. So, once again you're going to wind up with unintuitive behaviour and limitations for some use cases. For example, you can't register more than one resource with an inflowed transaction, you can't allow a context to be flowed into a node by more than one route and you need to register each subordinate node in the parent for recovery purposes. So, whilst this may provide a faster alternative to RMI/IIOP for simple use cases, it's not going to be an acceptable substitute for more advanced cases. Offering it alongside the traditional RMI/IIOP model is going to have implications beyond just the initial engineering, so the discussion may require input from docs, support and QE too. I'm pretty sure that e.g. support will tell you it is unacceptable to ship a solution that may require manual transaction cleanup. We've had a small number of corner cases in JTA that suffered that limitation and eliminating them and the support load they generate has been a high priority for the transaction development work. Intentionally introducing new ones is definitely in the category of Bad Ideas.