I was looking at the 'universal register login' functionality so would need the ability to modify the register and login interfaces an associated functions.
Universal registration is not such a smart idea, really. There are reasons why Facebook, Twitter, OpenID etc. all have their own different protocols. I'd also argue that people do not want all the options, but only the options that are actually relevant to their forum and users.
While I greatly appreciate the thought of and implementation of hooks (SMF has added some 200 hooks for 2.1+), I think that you folks may be doing a disservice by removing the full-code editing capability of the package manager.
I spent months weighing this one up. Here's the synopsis.
1. How many errors in core functionality are caused by mod errors, either soft or hard errors, exactly? (Soft errors are logic errors that merely cause errors or inaccurate behaviour, as opposed to parsing errors) How many 'I installed this mod and get a white screen' type errors are there?
2. Got a plugin that's causing fatal errors? Rename or remove the folder, the plugin is disabled. No mess, no nothing.
3. Got some errors in your forum? The error log will tell you which plugin caused them.
4. Not editing raw files means you never have to worry about permissions on the files, never have to change permissions of core files to make them writable (especially given how infrequently people put them back again)
5. You can make version dependency basically an irrelevance by making it detect what hooks and other features are available and only allowing installation if the requirements are met. (Plugins can also declare their own hooks for other plugins to work too.)
If people absolutely need to edit their own code, there's nothing to stop them, but the out-of-the-box experience should be to avoid doing that.
I would also point out that this isn't theoretical stuff. There are a couple of dozen plugins already existing; the calendar, birthdays, SimpleDesk, reCAPTCHA and plenty of others, have all been made available and all work without any file edits.
Also, we might as well compare SMF's implementation of hooks to Wedge's. SMF's can call some functions per hook, but there's only a few places where files can actually be loaded. In Wedge's case, hooks can load files, and they can also have a priority set so that some functions are called before or after others.
Mind you, let's be clear. I didn't 'remove' the functionality. SMF's package manager is still present in the code, but only until I finish writing the plugin manager - I built it all from scratch.