For the modules which are part of the core distribution this is a non-issue as they're branched. For PECL modules this is the same "how old of a PHP version am I (as the package maintainer) willing to support?". That package maintainer can: (A) Not use the new API, (B) Wrap up some #ifdef's, or (C) Use the new API exclusively and eschew pre-5.2.
Right, and that's why I think it's problematic to have such a major change in the API, because (A) and (C) are the likeliest outcomes - (B) is virtually unmanageable. Take a look at what it takes for an extension to adapt to this, and then imagine all of it #ifdef'd....
The important part of (A) is "not yet" (which I tried to express in my second paragraph). It's the same reason why userspace package maintainers aren't using exceptions and other 5.x specific features en masse *yet*, and why goto won't be used in many scripts when 6.0 is first out -- okay, not the only reason why it won't be used :)
As for (C), I can't imagine an extension maintainer going that route unless they have other *more compelling* reasons to give up on pre-5.2 versions. There's just not enough of a win to merit alienating those earlier versions *yet*. Noone's forcing module authors to break compatability with older versions, this is just giving them the choice to do so, and get a cleaner piece of source in the process. It's also making it so that when those extension maintainers do reach that point, they don't have to alienate the (presumably larger) pre-6.0 audience, they only have to do so for the (smaller) pre-5.2 audience.
I'm sorry Steph, I know your position, but I just don't understand it. This is a minor gain at no cost. Minor enough that it's not worth it to me to fight with you over it, but no-cost enough to compel me to against my better judgement... :)
-Sara