Now that this is well known, I have to point out the following:
Transaction malleability has been known and discussed many times— including padding and other encoding differences. Is there some reason that you believe the s-flip to have distinct implications from all of the other signature encoding differences?
The understood risk of this in prior discussions has primarily been that troublemakers could create confusion by changing the transaction ID of confirmed transactions to be something different than the transaction participants were expecting (so, e.g. they'd see two transactions doing the same thing, one which never confirms). There is a secondary risk that parasites could 'hijack' other people's transaction to pay the way to embed data in the blockchain for them.
I believe the originator wouldn't recognise the flipped transaction has spent his coins.
In the reference client the spent-ness of candidate inputs when drafting a transaction are checked with IsSpent(), the txid of the spending transaction should be irrelevant. Can you elaborate on what you're thinking here?