I can accept not supporting PSR directly but implementing the class autoloader and stating "internals believes autoload in should exist, just doesn't specify/support any particular implementation", this makes sense, although I like PSR and don't really see others that make (as much) sense.
This means internally we recognise an issue, resolve it in a general manner and allow some decisions up to the developer. Most of us developing now have the dreaded Utils class, it's an ugly hack filled with static methods... Yes, it might be almost the same as a namespaced bunch of classes, if you don't share states between those methods. Now consider this: PSR or any autoloader implementation allows for better sharing and code reuse; AND it makes sense to allow this for OOP as well as procedural code! I think Anthony and Nikki can see the forest from the trees, and that the core should support a number of use cases, not just what you currently use (and developers miss this functionality Anthony proposes) Having namespaced functions now allows for a function autoloader that uses the namespace as the file: awesome, great, let's do this! If not by looking at others code, or at Python, or at the Class/Constants/Namespaced-Functions all needing to have and being positively impacted by an autoloader... at least try and foresee the sense it makes for non-oop-but-maintained-by-smart-people to have an autoloader! Try to understand that this need exists and, it makes sense as a step into organising and refactoring legacy applications and for structure/grouping of classes, functions and constants, if only for the sake of organisation, but also for code-sharing, code reuse AND less managing of 20 *_once calls on top of every file in legacy applications! ;) Also as a bonus, a bunch of functions/constants filled files could got through a request never being read/included if never used, this alone should warrant pause!
