I agree that the fixing should be evolutionary. Although having a new PHP would be cool it would require an impressive amount of work only to port and test applications to it. This is financially not possible.

Thomas is right tho, a better release cycle would be great. If 5.x (or 6.x) releases happened every year (or 6 months or whatever) at the same date then companies could plan the upgrade ahead of time and feedback would be given much earlier. Also find a way to emphasize new functionality, there's still a lot of people ignoring the filter extension for example.

As for the bad API I think it 'could' be fixed by writing new extensions that would be kept alongside the current ones, that would become deprecated. For example write a new array extension and define it in its own namespace, so you would have an array::keys() for the array_keys() function. Recommend its use and wait a few years, then remove the old extension in a new major release. This would take time but it's feasible and would have the nice effect of cleaning up the global namespace. While feasible, I wouldn't advise focusing PHP efforts on this however. There's more important matters.

Please bundle the next major release with an "update script/extenstion/whatever" which notifies you about possible BC breaks, etc. and fix those annoying naming and parameter issues. (str_replace vs. strpos and $needle vs. $haystack, ...)

@Chris: We have been publishing an UPGRADING guide since version 5.1 as part of the php source as well as in the documentation. The upgrading guide for 5.3 is still not written (help appreciated) but this time we kept a "scratchpad" which will hopefully ensure that all changes will be noted.

Due to the dynamic nature of PHP (variable function calls etc.), writing a script is close to impossible. Or in other words, the upgrading guide will list the issues, but a script will not find exactly those issues which your eyes will not see easily either. Of course that is not to say there isn't any value in such a script (the ext/mysqli team once wrote a script for the migration from ext/mysql), but its not something we will focus our ressources on. If you want to step up and do this, you will however find that we will definitely support you.

When I hear "rewrite PHP", what I envision are fixing up PHP's internals to make it faster and leaner. While mistakes have been made (what language doesn't have any mistakes?), most PHP developers have learned to live with them and know the limitations and mistakes. While those are in the past, those lessons still remain for the future inclusions and additions... sacrifices have to be made, but there the area that sacrifices shouldn't be made are in the "core" of PHP, making up for any other deficiencies.

One way of fixing is along the lines of Loïc's idea, for instance, string functions:

str_replace (needle, haystack)
strstr (haystack, needle)

The namespace (namespace CompatMode, using CompatMode as default) can use the above format, while the "PHP6 strict" /default namespace can use:

str_replace (needle, haystack)
strstr (needle, stack)

In the proper orders. Perhaps that would be a viable solution. I dunno.

That compatibility namespace idea sounds pretty good, much better than mine. Legacy applications could still work on the new version with only a trivial change in their source code.

Love the CompatMode namespace idea.

One thing that I was kind of hoping for PHP6 was consistent function names.
The above is a prime example.
Some string functions start with str_, but a lot don't.
Some extensions use camelCase, others use_underscores, and others straightconcatenation. It would be nice if core php extensions followed a strict API style guide, so we could just stick with one convention rather than working with schizophrenic code.
Maybe a lot of this will be fixed up with the introduction of namespaces, but I'm guessing not.

str\replace($needle, $replace, $haystack) //looks fugly
String\replace($needle, $replace $haystack) //verbose, but looks nicer IMO
"Literal String"->replace($needle, $replace) //would be awesome

Don't really care that much which convention gets adopted, as long as it is consistent.

(btw, using code type="php" hides the backslashes)

Yes, the functions naming conventions also differ, but I think the reason for that was the PHP string functions that were analog to the C/C++ functions (strstr, strlen, etc) were kept that way; the functions that didn't "exist" per-say in C were given the underscore. That's how I understood it at least, to make that distinction.

Most extensions have seemed to stick to a guideline (ie, mysql), so the core don't bother me as much. Camel case, well, functions aren't case sensitive so that's ok. I like the 'shorter' not as verbose function names (str_replace, substr), etc