Contract killed twice

Question

Due to a delay (not minutes, but hours probably) in mining first a kill transaction https://testnet.etherscan.io/tx/0xf087a137e7f4962260da26928d205cabd71eed68fd79f8f35fb1027073f03812, and minutes later a second retry https://testnet.etherscan.io/tx/0x04658d7262ab966b6f83cce78529d02d66318e02aa59411ef1d18c1989f5f3fe (that's 2 kill transactions to the same contract) the contract got killed twice. I wonder if that's congruent with Ethereum standards. If the contract https://testnet.etherscan.io/address/0xabc7a3a72af1f94ff6029ef01bc0f7c49e2ed637 was killed in the first place, how is it possible that very same contract accept the second call to the method kill()?

At Waiting for transaction to be mined you may find details about the strange delay on testnet Ropsten when performing these transactions.

I thought Can you execute a contract twice in one block? could shed some light on this issue, but it is all about transactions on the same block, and it is not the case here, because those two kills belong to different blocks.

Answer 1

If you look at the Geth VM traces:

https://testnet.etherscan.io/vmtrace?txhash=0xf087a137e7f4962260da26928d205cabd71eed68fd79f8f35fb1027073f03812

followed by

https://testnet.etherscan.io/vmtrace?txhash=0x04658d7262ab966b6f83cce78529d02d66318e02aa59411ef1d18c1989f5f3fe

...you see that it only actually committed suicide the first time.

The second time it did nothing, since the code had been deleted by the previous suicide operation.

The unintuitive aspect of this is that the second transaction appears "successful", although it doesn't actually do anything.