Hopefully - not the excuse.
That's just a design flaw your talking about there which I doubt is part of SD ...
If there is a double spend, for the 2nd transaction that doesn't get into a block, all the transactions based on it will NEVER get into a block.
You can't 'fix' a transaction, you can only create a different one that then new transactions can build upon.
If the design flaw is there in SD, then it will be identified by the transaction number of the winning payment changing to a new transaction (though it can change for other reasons)
You can, however, detect the cause of the problem - follow the transaction tree back and look for 2 that use the same source - one will be in a block and the other will be a pending/orphan transaction
or, follow the transaction tree back and look for transactions that don't exist any more.
The payout transactions don't appear to exist anywhere. For example, look at
http://www.satoshidice.com/full.php?tx=7a1b4e1101385046795ef4518e6f037a35fab939c102faf72e9461fa11df6385 - it claims that the payout was made in tx
http://blockchain.info/search?search=58cdc16b3e009203fd2da56c11490109be63e1aa5f27d94cee40304556dd29eb but blockchain.info says that transaction doesn't exist.
I don't know if it's a design flaw to use 0-conf inputs to pay out winners with. It would certainly be preferable to use more confirmed inputs if possible, but maybe they do, and this problem we're currently seeing only happens when there aren't enough confirmed inputs available.