If a great feature comes up after development starts, too bad -- the next development cycle will usually be less than nine months away.
Bah. For most features, 9 months is an eternity compared to the time it takes to code it. About the only exceptions I recall are new-style classes and Unicode; major packages like email or xml also are exceptions, but they are usually developed outside the Python CVS tree first anyway.
It's not the time for coding that's the issue, it's the time for testing, documentation, integration, and so on. But even that's beside the point; this suggestion is being brought up in the context of the stability/change thread, and this suggestion would IMO go a long way toward changing perceptions.
It depends a lot on the impact of the feature. If something like list comprehensions came up at the last moment, I would agree to put it off. But something like sys._getframe() shouldn't need to wait 9 months, no matter how conservative you want to be. I don't think you can give hard and fast rules here.
For example, what's the cost in postponing the bool() change to 2.4? (I'm not talking about adding the builtin the way you just did for 2.2.1 (which I agree with), but changing the type of "not x".)
Note that I'm not pushing this suggestion, but I think your "Bah" is overstating the opposition.
I disagree with your suggestion to put off bool() to 2.4. I see no technical reason to do so, and I don't think politics should influence release decisions to this extent.
--Guido van Rossum (home page: http://www.python.org/~guido/)