0.8 doesn't need to be taught to reject anything, the problem is 0.7 and earlier reject valid blocks due to a bug in 0.7 and earlier.
0.7 can actually CREATE blocks that it will itself reject due to that bug.
This is incorrect. The reason the fork happened is because the 0.8 clients
accepted blocks that the 0.7 clients rejected. They kept on going based on that block and the 0.7 clients kept on going based on other blocks.
What needs to happen is that 0.8.1 should be released where its the same as 0.8 only it changes the default CONFIGURATION such that it will NOT create 0.7- incompatible blocks.
When over 90% of the network are using 0.8+ this limitation can be safely removed and people using 0.7 or earlier will be forced to upgrade.
It doesn't matter if 0.8.1 doesn't produce incompatible blocks because solo miners are currently and will continue to use 0.8.0, which might produce those blocks (this is even if we assume that 0.7 can't produce those blocks). Then, all those 0.8.1 clients will accept the incompatible blocks and will fork from the 0.7 clients once again.
If you want to avoid forks like this, you need to ensure an acceptably-large majority of clients accept and reject the same set of blocks. I think this is best done by a scheduled hard fork, but I haven't thought too hard about it.