"Would that include not adding:"
A whole bunch of completely standard features to add to a mutable-state dynamic scripting language, almost each and every one of which had been successfully added to a mutable-state dynamic scripting language before PHP did it? Of course not.
(I'm not sure about that last one, though I suspect one could find a version of Perl early into its reference experimentations that would have an equivalent problem. Even today, I'm not sure if a function that returns a list (not list ref) can be directly dereferenced into via [] notation. Or at least it's klunky. And let me clarify that I do mean added to an existing language, not programmed in from the beginning, which is a very different problem.)
I'd also add generators into that list.
Adding pervasive threading is a different story. Adding threading to a mutable-state dynamic scripting language has a long and sordid history... even when it is nominally successful (as in Python) it is still not very useful, and at times it has been simply a failure (like Perl).
As another example, though, I would suggest the principle would be firmly against trying to add Hindley-Milner typing to the language, or making some big move in an immutable direction. That's not PHP... that's not "mutable-state dynamic scripting language". I'd also suggest against burning any time in trying to make PHP not a "scripting" language anymore, on the grounds that Hack is the right approach; create a companion language that may integrate well, may even still be a "dialect" of PHP, but is not "PHP" anymore, and can do the non-scripting work without actually trying to bodge that into PHP proper.
"PS: PHP already supports threading via a PECL module."
Yeah. Perl "supports" threading too... for sufficiently small definitions of "supports". Unsurprisingly, when I googled "PHP thread" (without quotes in the search), once you get past what are for me the first three links which are for the documentation itself, the remainder of the results consist of people asking and/or explaining why you can't trust it or use it. Compare with the Google search for "perl thread". (Pretty much the same except with Perl, even the documentation warns you away from using it.)
PHP is a mutable-state dynamic scripting language. It can continue importing anything it likes from that realm as all the mutable-state dynamic scripting languages continue to converge on the same basic core of features, which I have in the past called CLispScript but really there's any number of things you could reasonably call it. Good threading support is not in that core set of features. The history of other extremely similar languages extremely strongly suggests it would be little more than a staggeringly enormous waste of time.
But of course, if PHP would like to ignore that history, go nuts. I see no reason to believe that its internals and API are so especially cleanly designed that threading will be a breeze to add on, but hey, go prove me wrong. (That might sound like a sarcastic snipe at PHP at first. And I won't lie, I don't like PHP. But the truth is simply that adding threading on 20 years later is insanely difficult if you haven't been planning for it all along, and that's pretty much regardless of the underlying language. If you have been planning for it it's merely very difficult. So very, very many things will fundamentally depend on the implicit lock that you get by everything being single-threaded that you don't even realize it until you try to add the threading on and realize just how thoroughly the assumption has been baked into the VM, the runtime, every library, every framework, every binding... everything.)
For another "see also", look at Javascript, another fairly similar language to PHP in the grand land of programming languages (mutable-state dynamic scripting language). There is a reason we have "Web Workers" and we don't have "Javascript Threading", and it isn't all "browser".
Incidentally, since for I don't even know what reason HN has somehow decided that my first post is unworthy, do note that it's a serious engineering question. Spending design capital on "keeping things safe for future threading" is not free, and if there really isn't any chance that PHP is going to be threaded in the future, you're better off claiming the bounty of staying single-threaded in the spec than complexifying it with things that will never be used, because being able to guarantee single-threadedness is actually a big win in its own way... if you've got it, use it. And, again, the actual history of adding threading to this sort of language is not very promising at all.
(Edit: A bit more searching finds a few people suggesting that PHP threading may be usable, though it made the transition to that quite recently. It still doesn't sound like it's something I'd touch after all the other times I've been burned in other environments with similar level of promises and experiences. YMMV.)