Even if the problem hadn't been found during testing, if miners had gradually rolled out the change to 0.8 (with a built-in bigger block-size limit), then when the problem cropped up, as long as 51% of the mining power hadn't been on the new "big block 0.8 release", there would not have been a hard fork.
The problem that cropped up is a hard fork, so by definition it would have happened. It's clear now that a hard fork is unavoidable. The only question is when does it happen and who will lose out because of it.
If only a few miners had been on "big block 0.8 release", they could have produced a block the rest of the world didn't understand. But, wouldn't the rest of the world continued on without that block? A single orphan block. I don't exactly consider this a "hard fork". Am I missing something, here?
The problem was that 51% of the miners were running an essentially untested combination of software and blocksize. Without manual intervention, the fork that evolved would have continued forever. *This* is what I call a "hard fork".
It's not that simple More than 51% of the miners were running 0.8. One single pool with a large block size created a valid block that all 0.8's accepted. All the 0.7 miners
and users rejected it due to the lock table overflow.
I don't believe this can happen again because >51% of miners are now on 0.7. Even if a solo 0.8 miner recreates a block that causes 0.7 to freak out on, it will find itself automatically orphaned.
Last night slush's pool was running 0.8 with the large txn blacklisted in order to get back onto the 0.7 chain. That helped converge the chains but doesn't count towards the ongoing "> 51% on 0.7" goal - it would have accepted a "new" 0.7-breaker txn as valid and contributed to that fork.