Where can I learn more about BIP30; namely the exploit and the background discussion?
The problem was that in case a duplicate transaction was created in a side branch that is afterwards reverted, and is only seen by a certain portion of the network, a fork risk exists. The nodes A that have seen the duplicate transactions and its reversal, will consider the original transaction unspendable (as it was overwritten and subsequently removed from their transaction database in the reorganisation), while nodes B that did not see the duplicate would consider the original spendable. When the original transaction is spent afterwards, and a majority of the network is in B, the network will split, as the A nodes will consider the chain created by B as invalid.

The third solution presented is implemented by BIP30 - this was a stopgap solution to prevent the worst from happening. A more complete solution (the first one) being deployed as BIP 34