As a result of an "official" change in back-end databases from BDB in v0.7 to LevelDB in v0.8, in addition to an increase (by some mining pools) to a higher block size limit, there was recent "hard fork" at blockchain height 225430.
Miners were originally told to switch back to v0.7, but then later informed that v0.8 was fine as long as they don't increase the default (256kb -- soft limit) block size.
So what happens to block 225430 for v0.8 miners? Are they required to reload the database from <225430 with new "max block size" limits? How did this problem supposedly just fix itself (as has been reported here), or is this still a problem as blockchain.info continues to "sequentially" report orphaned blocks here? My last question would be what happens to the transactions that were linked to block 225430 (and are now UTXO), won't v0.8 still consider them spendable?
I'm sure this all would make a lot more sense if I had a better understanding of Bitcoin's block
reorglogic. Perhaps a pseudo-code walk-through of the process might help.
Edit: the 2 chains seemed to have merged here (after 32 sequentially orphaned blocks). So how exactly did v.0.8 clients handle the reorg for 32 blocks? Is there a maximum reorg that Bitcoin can handle? Was it easier to double-spend during the 5+ hour blockchain correction?