XA COMMIT is done by running hton->commit() for all participants. Typically in InnoDB-only transactions there are only two participants, binlog and InnoDB, and binlog is the first. But if we trick binlog to be the second (by starting the transaction from non-InnoDB statement), then InnoDB will commit first. That will release all locks, possibly allowing some other transaction to continue, commit, and reach binlog before this transaction's XA COMMIT gets binlogged. Test case:
binlog clearly shows that first transaction updates the row from (5,5) to (5,50), then the second transaction updates (5,50) to (5,10), then the first transaction commits.
In the replication the slave would be stuck on the second update, ultimately timing out.
This bug would be easier to repeat if one adds a delay between commits in different participants: