I understand that it is not a requirement anymore that changes to Python 2.2 are "pure bugfixes". Instead, people expect that Python 2.2 evolves and continues to grow new features, as long as they are "strictly backwards compatible".
Alex made a case here for "new features", but the Python Business Forum hasn't shown interest in that. Like most businessfolk, I expect they'll ignore such issues until someone discovers that the lack of a new feature is putting them out of business <0.8 wink>.
For any user-visible feature, it is normally debatable whether it is "strictly backwards compatible", since it is, by nature, a change in observable behaviour.
This specific case is not in that category (i.e. has no user-observable behaviour change), so I think it qualifies for 2.2 - provided there is enough trust in its correctness.
The "bugfix part" of these changes certainly had user-visible aspects, in that before it was possible for objects in older generations to get yanked back into younger generations. This can affect when objects get collected, and so throw off over-tuned programs slinging gc.enable() and disable() "at exactly the best time(s)".
... I'm concerned that backporting more changes to Python 2.2 will become difficult in that area, if the GC implementations vary significantly.
Maintaining multiple branches is always a PITA.
Maybe this can be reconsidered when there actually is another change to backport.
Anyone who is so inclined is welcome to reconsider it non-stop <wink>.