"If a transaction is prepared (XATerminator.prepare()) and then the connection is lost, then the transaction is "stuck" in the prepared state - we aren't going to do anything about that at the protocol level. But presumably the transaction coordinator would be able to automatically recover once the resource was made available again, as the transaction isn't "busted", it's just not fully completed."
Well that really depends upon what the participant does or, even worse, what other participants do in the same transaction. For instance, it could decide to autonomously roll back, and in which case we're in heuristic land. So the transaction could well be "busted" in as much as we now risk not having an atomic outcome. Some error codes from XA allow for the transaction manager to periodically retry operations on the RM. A heuristic isn't one of them.
"If the same scenario exists but the commit was received and acted upon (but it failed), then I guess this is what you refer to as a heuristic outcome, and, well we're not going to deal with that either; presumably our recovery tooling will work exactly the same way in this case as it does in the case where the same thing happens to your database connection."
No, in the scenario you just mentioned the recovery subsystem would retry and either get back a "didn't you get my message" response (c.f. XTS) or eventually decide that the RM did commit and it missed the message. Remember that we're using presumed abort semantics here.