That was my point actually. I was not accusing the developers of negligence I was saying that his platitudes are a form of "I could have done it better then them if I was them and could see the future". Well, he isn't them and they didn't see the future.
Then we are in violent agreement! Hooray!
If the network ditches 0.7 then there is no problem.
As long as the network is predominantly 0.7 this would result in you creating a single orphaned block rather then a fork. While certainly a waste, this could happen while using 0.7 to mine as well (for a different reason).
All true, but I suspect you underestimate the, uh, conservatism that makes "the network ditching 0.7" non-trivial. That may end up being the chosen way out, and Deepbit, Eligius, etc., will plan to upgrade at an appointed time. Or another solution may emerge. We've waited months for 0.8, and we can afford to wait a few more days or weeks, though the newly discovered 0.7 bug adds a reason to move.
In retrospect you are right.
The best solution would be to make a new release that does both A and B concurrently.
That is, make a version of 0.8.1 that:
A. Has a block rejection algorithm that will reject non 0.7 compatible blocks - must be programmed first as such a thing does not exist
B. Is configured to not generate non 0.7 compatible blocks - functionality exists, it just needs to be configured.
Both of those can be set to expire after a certain date.
This would make v0.8.1 superior for mining than 0.7 because even though it rejects the same blocks 0.7 does, it has the advantage of not ever generating such blocks (which would be orphaned). Mining on 0.7 is thus more risky as there is a chance that you will generate a block that will be incompatible and orphaned.