It turns out that "non-issue" might have been a slight exaggeration. I can understand where the Bitcoin developers are coming from. I mean no one likes to admit there's a bug in their code. Just read through Microsoft support archives. How many times will you find that some bizarre, head-scratching, counter-intuitive behavior of some API or other is "by design"? Does that mean they won't eventually (quietly) patch it? Of course not.
The bitcoin developers "admitted" long ago that that behaviour is not quite optimal, and they are actually working on fixing it, albeit not quietly, because that would risk breaking bitcoin, as would doing so fast.
It's a non-issue in so far as it does not prevent bitcoin from working as it should if you do implement things as the original client does it, it's only an issue because it's something you might easily get wrong when implementing a new client (which apparently happened to some other developers), and it would have been avoidable - but changing the behaviour now has to be done very carefully, coordinating with all implementors of bitcoin clients, in order to make sure the fix does not cause a blockchain split, so that is what is happening.
Yes, but the bitcoind reference client fails safely: the child transactions are orphaned and no funds are lost. It's behavior alone is not exploitable.
Unfortunately it does not fail completely safely. The change transaction seems to still be available for coin selection and causes sends to fail. The getbalance command shows an incorrect balance due to counting the change address twice - once in the double spend and once in the accepted. The accounts system also has balances messed up which some merchant sites rely on.
It is not "lose money" exploitable (unless combined with social engineering) but is definitely "lose time, lose effort" exploitable.
