There is no reason to stop transactions, they work fine if you are using properly coded clients.
A lot of people seem to overreact to this malleability issue without fully understanding the problem.
I personally don't care if my "transaction ID" is changed because it doesn't affect the actual outcome of the transaction.
It does if your client uses unconfirmed change in a new outbound tx (which all of them do BTW). The changing of the tx id will cause the child transaction to become invalid.
A temporary fix would be to
a) give users the ability to require change to have 1 confirmation before using it in a new tx.
b) flag duplicates txs and hide them so the user only sees one (and the balance only reflects one copy).
It isn't perfect but it would make the mutability a non-issue for ends users. Service providers which keep records on outbound txs would still need to ensure they don't rely on tx ids.