How can I avoid transaction malleability consequences? Please note that this question is NOT a duplicate of other questions regarding transaction-malleability.

My question is regarding a following scenario, that could happen on an exchange that uses on-chain wallet management:


user deposits funds on address A, belonging to his account on an exchange. Exchange waits n confirmations before it credits user account.
user then moves funds from address A to address B, which also belongs to his account on the same exchange. Exchange doesn't wait for any confirmations here, because the it knows it won't double-spend itself. Exchange thus notes the TXID of this transaction for future use.
while transaction is unconfirmed, someone exploits transaction malleability issue and pushes its tweaked version, which gets picked up by miners instead.
in the mean time, user wants to withdraw funds to address C, which is another exchange or external wallet. Exchange creates this transaction using TXID that it stored earlier. Unfortunately, Blockchain doesn't know this TXID because it was rejected by majority of miners. The exchange though doesn't get immediate feedback about that, because it doesn't know that a tweaked version of that transaction exists (since both are still unconfirmed)
in effect, funds are not withdrawn, and exchange operators are left wondering why this happened.


Now the following situation has NOT happened to me (yet), but I'm wondering:


is it realistic enough that it could happen, or is there something I missed?
how I can guard against this? For me it seems that the best fix for this would be use of the new NTXID instead of TXID in transaction inputs. But that will probably not be possible in near future, because required quite a big change in the protocol.
This is the new issue, the one that's causing all the trouble. You basically have two choices:


Don't spend any of your own outputs until you're quite confident they're fully confirmed. For example, you could wait for three confirmations.
Be prepared to deal with this problem by monitoring your outstanding transaction chains and re-issuing any orphaned transactions with new input transaction IDs.