Definitely agreed, here's a few points:
1) We use local upgrade significantly to modify core db tables, and, yes, I understand this is at our own risk, but I bet lots of other people do it too.
Just one 'edge case' issue... I agree that upgrade should run at consistent time (after everything else), however I wonder if there should be a 'pre-upgrade' event hook that local could use. This would deal with situations where we have done something evil to a local table and it breaks the core update.
pre-upgrade: local event handler undoes evil thing to table
upgrade, core: standard upgrade changes table and now works
upgrade, local: local upgrade re-applies evil change to table
probably not an absolute requirement or anything, but it might help if possible. However this would require for the event system to be in a stable state (or at least capable of recovering) when there has been a code change but no db change yet... which perhaps is why not using the event system has been so popular.
2) I guess that where local plugins *do* want a user interface, they are supposed to achieve this by defining a settings.php? (Which could then include links to their other scripts or whatever.) Which is something you listed as a local feature but haven't said how it will work yet? That's fine, just checking.
I would say this is going to be a big migration task for us but in fact I think we will throw away local/* when we finally upgrade to 2.0, and put back anything that we can't do without one feature at a time, creating new plugins as we go... and somehow somehow work out a database
migration strategy... so frankly, changing local to a plugin system doesn't make much difference as we would basically have to redo it anyhow.