Of course, noone in this day and age would make any dodgy design decisions... would they?
If the PHP people are unhappy with them, they could do exactly the same, deprecate and remove the original names through a couple of major releases, and the problem is solved as well. Same solutuon for parameter order (needle, haystack, whatever).
Really I don't understand all the fuss around PHP functions names.
You could add aliases to all functions in php in your company, but then you would need to teach these aliases to all new developers. Also every company would have different aliases and people changing jobs would need to relearn everything.
So aliases are theorethical solution that nobody use in practice. Changing the standard makes a new common language that you can actually use.
However, changing the function names (especially some of the core ones) is fraught with backwards-compatibility issues - PHP code written 15 years ago should, for the most part, still work, and not enough hosts out there run with the right error reporting to point out deprecation warnings, so you would probably end up with a lot of PHP sites with code silently failing when a host upgraded.
In fact PHP HAS depreciated functions over it's life, so 15 year old code might not run on modern web servers anyway. Yet we still have the same function names where they should have been renamed.
* new security threats that have been discovered in that time which needed to be coded against (In the last 15 years, a lot has changed with the approach we have to building secure sites).
* newer web standards and browsers - thus compatibility on the client side might now be an issue.
* different computing paradigms (we use touch interfaces where hover-over menus wouldn't function. There's a massive range of different client side screen resolutions and aspect ratios these days too).
* different methods of sharing content (for some types of sites, supporting OpenGraph and Twitter Cards is pretty important if you depend on your content getting exposure from "word of mouth").
* different user expectations (a 15 year old site is unlikely to look any good compared their modern counterparts. While that might not matter for some sites, if you're trying to generate traffic from the average layman, then they might be put off and prefer a site which is more aesthetically pleasing).
So if someone is trying to port 15 year old PHP code to a new server, then I'd expect they'd want / need to do a sizeable amount of rewriting anyway - regardless of API compatibility. In this instance, API compatibility is the least of their worries as you can at least just use the 'find/replace' tool in your text editor to fix renamed APIs, where as fixing the other issues (eg switching from the older method of dropping variables into an SQL string, to the current preferred method of parametrized SQL which negates the risk of SQL injection attacks) will take much longer.
I have seen many a framework and language (the sort that you might see hyped on this website) that make drastic changes and only their most ardent fans stick with the new version. It's often an opportunity to switch to the next big thing.
ie version 5.6 will raise a warning when some_function is called, saying that some_function will be depreciated in future versions of PHP. So you have both the old and new functions running in parallel for a while. Then a couple of major versions later, you drop support for the older function name.
As I said before, PHP has already been doing just this for some stuff for a while now, so it's not an alien concept to PHP developers.
I'd have expected (hoped) that by the time of the last major release (v5.0) the chief PHP devs would have used that opportunity to to rename some of the core functions. By that point PHP's popularity was already established and the shortcomings of it known. Plus as there was already a major Zend rewrite under way, to me it seems a sensible time to throw in a few in a few niceties to beautify / simplify the APIs.
Perl -PHP's spiritual predecessor- managed to tidy itself up circa v5.8 and now, ironically, Perl is cleaner language to code in despite the jokes about it being executable line noise.
[1]:http://www.oracle.com/technetwork/developer-tools/adf/overvi...
Hence you could GEM a page or PUN an object. I'm not sure I want a codebase that's "brutally optimized" to the extent that it's not functionally equivalent.
EDIT: Used "functionally equivalent" as a more proper phrase than "idempotent" after the below feedback
The code simply does not perform the same rigor as slow, spec-following code would.