Hopefully the changes to the proposal now answer your questions. We will be using spl_autoload_register to register Zend_Loader_Autoloader::autoload(), but then have Z_L_A maintain its own registry of autoloaders. The rationale behind it is to simplify the process of registering autoloaders, but also to work around deficiencies in spl_autoload (which often has trouble when re-registering instance methods as callbacks).

Noted. Thanks!

The idea would be to deprecate Zend_Loader::registerAutoload() in favor of Zend_Loader_Autoloader. (We may even have it proxy to it.)

The benefits are several:

• Better error handling capabilities. This has been a constant issue with using Zend_Loader::registerAutoload(), as some people want to have parse errors bubble up, and others don't want warnings when files aren't found (as they have other autoloaders that can map the class to a file). By having a central autoloader registry, we can make this much cleaner.
• Ability to restrict which namespaces are in use. (Leads to faster lookups, and also ensures that developers are explicit about selecting third party libraries for use with their application. That said, we allow it to act as a fallback handler, too.)
• Zend_Loader_Autoloader would use Zend_Loader::loadClass() internally. However, this keeps a separation of concerns: one has a mechanism for loading classes and files, the other performs autoloading and handles an autoloader registry.

Finally, as noted in the proposal, this also works around issues we've noticed with spl_autoload_register when used with arbitrary instance method callbacks.

I'd like to keep a clean separation of concerns, which is why we're suggesting a new class.

There's no reason to have a separate autoloader for each namespace when the implementation is the same. The motivation is to speed up lookups and prevent unnecessary lookups (if the namespace isn't in the list, just return false immediately instead of trying to load a file).

Autoloaders implementing the interface will be used for custom autoloading – such as with the resource autoloader – where there is not a 1:1 class/filename relation.

And yes, you're right, there should be popAutoloader and shiftAutoloader methods – I'll update the proposal to reflect that.

The problem with using add/remove is that with autoloading, we actually need to maintain a stack to ensure order – you need to be able to specify which autoloaders have precedence. I'm actually thinking unshift/push are all we need, as remove would allow you to choose which autoloader to remove, while unshift and push add to the stack, but tell you where to add them. (btw, removeAutoloader() is in the class skeleton)

The collection object makes sense, though it adds more complexity. That said, I'll definitely consider it.

As for 5.3 namespaces, we'll address that more in the coming months, but both Zend_Loader and this component will need some minor changes to facilitate usage with 5.3. We need a final API on namespaces before we even consider doing so – and even though namespaces are considered a "done deal" for 5.3, until there's a beta out, the API can change.