I'm having trouble understanding the bug that was fixed in BIP030, and how it would be exploited.

Is the premise of this attack that there would have to be a netsplit and the chain was forked, then subsequently rolled back the old transactions?

What would the validation psuedo-logic of the following look like?

There are several potential solutions to this problem:

• Guarantee that all coinbases are unique, making duplicate transactions very hard to create.
• Remember previous remaining outputs of a given transaction identifier, in case a new transaction with the same identifier is added.
• Only allow duplicate transactions in case the previous instance of the transaction had no spendable outputs left. Removing a block from the chain can then safely reset the removed transaction's outputs to nothing.

The reason I'm asking is so I can develop additional validation rules that work in parallel with the existing client.