This will be long. I've read over the Future Stability thread and taken it in, and decided to mull over an idea I touched on over a decade ago that I think might help. Also, in the interceding years the JavaScript community has overcome a compatibility issue using this technique, so we might do the same.
The crux of the stability problem is the need to update functions without introducing a BC break. Adding in new features without removing old ones also makes it confusing to incoming programmers as to what to use. I propose PHP Modules to hold new features. The existing namespace and functions would be left alone. Existing files would also not be affected - the behavior of PHP modules would be entirely opt in. They would work similar JavaScript modules - they would use the import keyword and the include, require, include_once and require_once directives would pitch an error if used in a PHP module. PHP Modules also would not parse as templates at all - no opening <?php tag needed (and yes, I know that will be a headache for IDE makers, but it's not insurmountable). PHP would have a new ini directive to use them similar to the "type": "module" directive that npm uses now. If that ini directive isn't set, php files would be handled as they always have. mphp files would always be handled as php modules though and lphp (legacy php) would always be handled as legacy php. I expect some objection to file extensions affecting parsing behavior, but over the last 5 years this approach has worked for the JavaScript community with cjs, mjs and js files. Here the existing php, phtml, php3, php4 extensions are handled as the directive instructs them to be handled, only the two new never before used extensions of lphp and mphp would do their thing. In a PHP module a function has to be imported before it's used with a handful of exceptions. The root namespace of php modules is utterly empty, or as close to empty as makes sense. The existing functions would be gathered into modules so that they can be imported. While this is done the headache inducing inconsistencies like haystack, needle for strings and needle, haystack for arrays can be addressed. I really don't care which is adopted, but having one order for this language wide would be nice. Also, decide once and for all - camelCase or underscore_case. The above alone would be massive. Maybe it's impossible given the number of devs available. The one thing modules can do that the current system cannot is allow devs to pick which version of the module to use: import split from 'php.mb' // imports the mbsplit() function from the current version of PHP. Say the mb module gets some bc breaks. We can put them into a new module so that the behavior is once again opt in. The strongest way to do this is to make composer a 1st class part of the language and let it specify the version of the module that is loaded. The import command would be able to pull from the file system or from the import map as JavaScript does currently. For ease of dev headaches I'd recommend hewing to the JS model as close as possible as it is proven, and many of us already use it anyway when developing browser code. I hope this helps, or at least spurs a conversation to come up with something to address this issue.
