What I still do not fully understand is whether capturing and manipulating the transaction ID of a transaction would result in neither the original nor the modification making it to confirmation due to the perception of a double-spend attack, or would one win out and in all cases the desired transaction is accomplished.
The former constitutes a potentially severe DOS attack. The latter would not be that big a deal (in my own use-case and as far as I currently understand.)
Or is it the case currently that the end result of an intercept+modify_hash+redistribute attack would be somewhat left to chance due to differences in the protocol implementation and such-like.
Before there were griefers on the network mutating transactions it was safe to spend your own unconfirmed change, because you could reasonably assume that you weren't going to invalidate your own transaction.
Now it's no longer safe. because you don't know what version of your transaction is going to make it into the blockchain, therefore any transactions you make that reference unconfirmed change will fail.
This is bad news for wallets that do not manage their outputs well. I'm interested in seeing how these single-key wallets like blockchain.info are affected. Any wallet that tries to keep its entire balance in a single utxo is going to only be usable for spends once per block.