The proper way to resend a transaction is to re-use an input which was used in the original transaction. It does not need to be all the same inputs, just at least one. This way it is not possible for the two transactions to both succeed. If the original transaction succeeds then the second will be rejected as a double spend.
In general Mt. Gox's software appears to not be paying attention to little details about inputs. For a while now if a miner sends the block find award to their Mt. Gox address then Mt. Gox will use the inputs resulting from that block find before the inputs are valid. This causes any transaction with said input to be ignored. The proper solution is to wait the ~100 confirms before using the new btc.
Note that this is a separate problem from the duplicated transactions. The point is: Mt. Gox is not tracking their bitcoin at the correct granularity. They appear to have written the software like we might use the bitcoin rpc api, without paying close attention to the details.
I'd say that malleable transactions are a bug in the protocol.
AKA a bug.
For those interested in finding out what transaction malleability is:
http://www.coindesk.com/bitcoin-bug-guide-transaction-mallea...
<quote> What is transaction malleability?
It’s an attack that lets someone change the unique ID of a bitcoin transaction before it is confirmed on the bitcoin network. The change makes it possible for someone to pretend that a transaction didn’t happen, if all the right conditions are in place. </quote>
This is a fatal design flaw in any TPS system. From any sound accounting principles point of view, no journal entry is to be manipulated after insertion - only through compensating transactions (referencing the original).
There are other ways to track transactions other than the txid, for example by tracking a unique output address. A normalized hash routine has been added recently: https://github.com/bitcoin/bitcoin/pull/3656#issuecomment-35...
Just a naive suggestion (will this work?):
Why not introduce some sort of a 2-phase commit with the original transaction and the newly inserted one on the block-chain? So, before the block-chain transaction is committed, check the two transaction id hashes, if they are different for the request, fail the transaction.
Edit: Of course, the eavesdropper could just as well pass the expected hash back to the originator anyways. :-( Hmmm
The biggest flaw here is probably the name "transaction id", because it suggests that a transaction can only have one valid id. The normalized id fixes this issue for most transaction types.
In fact, it's hard to even call this a flaw in design, because your intentions and hopes for Bitcoin might be very different than those of the Bitcoin developers.