The bug is that in all versions of bitcoin prior to 0.8 the maximum number of transactions that can fit in a block is not universally definable, because the limit varies based on the exact hardware and software configuration a particular node happens to be running.
It's possible for 0.7 nodes to produce valid blocks that other 0.7 nodes can't process.
And yet the current solution is "everyone use 0.7 not 0.8". BTC and all other mining guilds switched back to 0.7 to prevent a hard fork.
How can you migrate off of the buggy version when attempting to migrate off of it causes a fork?
No, not true.
What we need is:
1) end users to get off 0.7/below and need to upgrade.
2) merchants to get off 0.7/below and need to upgrade.
3) when people run a miner program as part of a 3rd party pool, still need to upgrade. Their pool runs 0.7, not the person running the miner.
4) a couple of large pools stay on 0.7 to buy time for #1/#2/#3 to happen.
"Upgrade" includes upgrading their bitcoind/bitcoin-qt etc to 0.8+ OR setting the DB_CONFIG entries mentioned above. The DB_CONFIG changes will fix the problems *that we know about* in 0.7 and earlier. Naturally there's still potentially more problems in 0.7 lurking.
However, those pools running this 0.7 bitcoind cannot "fix" the DB_CONFIG settings - if they did they might as well just run 0.8.
Once the vast majority of nodes are "fixed" (there's only 10,000 of them), then the big pools can go back to 0.8. (nodes:
http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html)
The reason 0.8 can't be taught to reject valid blocks that will break 0.7 and earlier is that there's no exact number. It's an internal artifact that depends on the run-time state of an individual node. For example, it has been observed by some folks that simply stopping/starting bitcoind 0.7 will cause it to validate and accept the block their copy had previously crashed on.
The "pools on 0.7" thing is just a tactic to by time for people to upgrade. It is not a solution, and it won't last.
Prediction: the moment sufficient hashpower switches over, somebody will generate another BDB-buster. It probably won't be a big pool, but somebody who wants the transaction fees will do it.