So the input wasn't even re-signed. The old signature was simply left-padded with an extra zero byte, changing the txid.
Just to re-iterate: this kind of modification,
transaction malleability, is something that can be done by miners without the person who submitted the transaction even knowing. In other words that "high-roller" may not have had anything to do with the double-spend at all.
It's especially ugly because an evil miner can simply watch the mempool for
all losing satoshi-dice transactions, and then modify every one of them and attempt to mine a block filled with now-modified transactions. Of course the miner doesn't know satoshidice's secret, so they can't pick winners or losers - they are essentially rolling the dice again - but for every game with a win probability of p your new win probability will be p + p^2. For instance if you bet on a 50% chance game, you'll now have a 75% chance of winning. On a 25% chance, you'll now have 37.5% chance.
In fact, it can be done by a non-miner who is well connected too: again, watch for satoshidice wins, and this time use a form of transaction malleability that is a standard transaction and thus will be relayed by other nodes. Now immediately broadcast the modified transaction to as many nodes as you can. The vast majority of the time nothing will happen - the modified tx won't be accepted because nodes already have the original - but every once in awhile it will happen to be accepted by a miner and get confirmed.
A simple way to fix this issue would be to first only accept bet transactions whose inputs are confirmed, and secondly change the lucky number algorithm from hmac_sha512(secert,txid:out_idx) to hmac_sha512(secert,txin_1:out_idx | txin_2:out_idx ... | txin_n:out_idx) This works because the betting transaction refers to the txin's by hash, so if you change the betting transaction hash, the lucky number doesn't change, on the other hand the txin's are already confirmed in the chain and can't be changed. Note that you'll need to ensure the SIGHASH bits in the signatures are their standard value; ANYONECANPAY still allows changing the txin set without invalidating the signatures. Of course regular double-spends are still possible, but at least they can't be done by a third party.
Note that having the txin's be confirmed is essential: if they aren't you can pull an even worse version of the same trick by modifying the txin hash, thus invalidating the bet transaction.
EDIT: While we're at it, I also noticed that satoshidice is accepting transactions with non-default SIGHASH's for the signatures. For instance I just made
bde69c82fa0870bb156edb334da4a8013d5d385e93608110313a8695184d6365 with the signature using SINGLE|ANYONECANPAY, which means any node on the network is free to add their own inputs and outputs to the transaction provided they do not modify the one input and one output I signed, again changing the tx hash. It's a more minor issue, but it would allow people to setup co-operating decentralized double-spenders without even having to communicate what transactions to double-spend too.
EDIT2: The really interesting thing would be to come up with a form of malleability that is undetectable after the fact. Satoshidice could also just not transmit wins when the second, winning, transaction gets mined. They can prove their honestly by just pointing out that the second tx was modified, and the first was normal. However if you can come up with a form of malleability where both transactions are indistinguishable there will be know way of knowing if the miner turned a win to a loss or vice-versa, and hence satoshidice doesn't have much choice other than paying out the wins. At this point they simply have to change the way wins are calculated.
.
