However it is a genuine case for concern. There is no profit in it, but the combination of:
a) malicious user malling all tx
and
b) the QT client using unconfirmed change outputs in new tx
can lead to a lot of confusion and broken transactions. I am not sure what the immediate fix it.
It really is not that much of a problem IMHO. If those change outputs will eventually confirm or not has nothing to do with mutated TxID. If someone wants to include unconfirmed change outputs as his new inputs that's his problem. His last transaction will eventually confirm if those outputs are regular payment, or fail if it is double-spend attempt. The system is designed to work this way.
I think you are misunderstanding.
I send you 1 BTC. It is tx id A. Someone mutates it so there is a copy with tx id B.
You send a 0.1 BTC to your friend. As a normal user it isn't you, but the QT client which picks which inputs are used. The client picks tx id A, index 0 as the input for this new outbound tx. It can do this because by the QT client right now uses unconfirmed change outputs as inputs in new txs.
Now lets say tx B not A ends up in a block. Oops.
The tx to your friend is now invalid, it uses as its input an output which is a double spend (tx a) of a valid confirmed tx (tx b) and thus will never confirm. There is no user friendly way for you to remove that from your wallet. Most users may not even know why it didn't work. They will see the tx to their friend simply never confirms. It won't be marked as a double spend (because it isn't) it simply will never confirm because it is no longer valid, it became invalid as soon as B not A was included in a block. It can be solved but it is far from user friendly. Now imagine that happening for thousands of users every single day forever because some malicious user is intentionally mutating tx to cause chaos. Nobody ends up losing coins but it makes the system look bad, counterintuitive, and confusion especially for newer users.
If you wait until a tx is confirmed then the txid is immutable (baring a network re-org) and this becomes a non-issue. Right now there is no way for an average user to force the client to only used confirmed change in new transactions even if they wanted to, other than manually wait and make sure they have no unconfirmed change outputs before sending funds.