This is incorrect.
The standard wallet software considers change from a transaction to be immediately available, and usable as an input to a second transaction.
If the first transaction is replaced by a rewritten one, the second transaction becomes invalid, and will never confirm.[/q]
What's that got to do with the malleability issue? I mean, regardless of the malleability, I could just as well manipulate the client and build a customized version which considers spent input (from a transaction that is not confirmed yet) as still available, allowing me to do a 2nd transaction with it. Essentially this approach is just another attempt to double spend, which won't work.