Quoting what I said above: "Upgrade" includes upgrading their bitcoind/bitcoin-qt etc to 0.8+ OR setting the DB_CONFIG entries mentioned above.
AND not OR.
There is no point in setting anything in 0.7-;
0.7 can NOT make a block that 0.8 rejects.
0.7 AND 0.8 can both make blocks that 0.7 will reject due to a bug in 0.7-.
0.8 can be configured to only make blocks that are accepted by everyone.
When everyone was on 0.7, if it made a block that it itself rejected than nothing bad happened. with 0.8 you had the fork risk suddenly come up.
If you are going to be messing with your install then you should do so by switching to 0.8 with the right config not by trying to mess with the bugged 0.7
Releasing a 0.8.1 won't fix anything. All that it can do is clamp the value that you can set the max generated block size to. The problem is the code is still there, and so is 0.8. If somebody wants to compile a custom 0.8.1 from source with the limit at 1MB, they can.
Default configuration is included in the source code and as such anyone who compiles an 0.8.1 without explicitly altering said code would get the new configuration.
If a person (or a pool) wanted to cause trouble, they could simply change the code in their 0.8.1 checkout and compile, or use 0.8. Of course they need to be able to solo-mine their own blocks. Generating a block that's complex enough to overflow the lock tables of old 0.7 bdb based systems is still valid. If more than 51% of the hash power applies the DB_CONFIG fixes (even on 0.7) then they'll accept it and build on it.
This wont cause trouble to anyone except for themselves, they will be generating blocks that are rejected by the chain until and unless 51+% are using 0.8+, at which point those using obsolete bugged version are forced to upgrade.
What actually needs to happen is a new fixed 0.6.x, 0.7.x need to come out
There is already a fixed 0.7, its called 0.8.