Thanks for the input. Are you quite sure that that is empirically the case, or is it more theoretical? (That is, transactions work as always whether attacked or not, but one must rely on confirmation rather than transaction hash?).
Yes it is empirically the case. A node will become aware of both copies of the transaction. If you create a given tx (assuming it is otherwise valid) the tx or a copy of it will eventually be confirmed and an attacker can't use this to block transactions, freeze transactions, or destroy transactions. No core element of a tx can be changed (the inputs used, the number of outputs, the address (well PubKeyHash) of each output, any part of the output script, the value of each output, or the tx fee).
Right now the bitcoin client will display both copies although that is more a reporting issue than an issue with the network itself. There are pull requests being considered to handle this in a more logical manner (only show one copy of duplicates to the user, only include one copy in the wallet balance).
For my part, I rarely make more than one spend per block cycle. I'd be totally fine not spending unconfirmed outputs and would be totally fine doing my planning to adhere to such a policy. I typically only make a handful of transactions per month (if that) and feel pretty guilty about every spend I make since they are highly subsidized. I voluntarily pay an unusually high transaction fee.
Then you should have no issue with the issue of broken unconfirmed change outputs. There are pull requests being considered which will give you the ability to require 1 (or more) confirmations on change before spending in order to avoid even accidentally spending unconfirmed change. Once confirmed the tx id is immutable baring a re-org of the network.