It seems that when appending a transaction via plugin, to the array of current transactions, by definition it should be part of the same history block
The semantics of appendTransaction name is not correlated to the documentation, where it is stated that is to “append” a transaction to be applied after the recently applied transactions. But in this case the name should be more like “addTransaction” or “queueTransaction”.
The name “append” implies that is attached to something, but currently with appended transactions there is no guarantee that when the transactions are “appended” to a existing one, they will be part of the same history group.
In the history module, appendedTransactions are still dependent of the time between changes, so if for example a transaction is appended via plugin and its creation time can’t be guaranteed to be within newGroupDelay value, it will belong to a different undo step, even when what fired the appended transaction creation was the previous transaction (and thus should be considered a unit)
To me, appendedTransactions should be really part of the same history group of the transactions that fired them, or at least there should be a meta to signal that and avoid being dependent of time between transactions.
It might be that the appended transaction takes a long processing time, or it might depend on network conditions, but apart from that, debugging introduces artificial pauses while stepping each statement, and makes the transaction to be added to a different history group, complicating getting real results.