Thing's I'd like to see in extensions and shipped with the default install (maybe not each item in it's own, a lot of these could be grouped)
Maintenance reports * Broken redirects * Dead-end pages * Double redirects * Long pages * Oldest pages * Orphaned pages * Pages with the fewest revisions * Pages without language links * Protected pages * Protected titles * Short pages * Uncategorized categories * Uncategorized files * Uncategorized pages * Uncategorized templates * Unused categories * Unused files * Unused templates * Unwatched pages * Wanted categories * Wanted files * Wanted pages * Wanted templates Recent changes and logs * Gallery of new files * My watchlist * New pages * Recent changes * Related changes Media reports and uploads * File path * MIME search * Search for duplicate files Wiki data and tools * Popular pages * Statistics (just the presentation, not the backend system) * System messages Redirecting special pages * External links * Random page * Random redirect High use pages * Most linked-to categories * Most linked-to files * Most linked-to pages * Most linked-to templates * Pages with the most categories * Pages with the most revisions Page tools * Compare pages * Export pages (not the api, which can do this) * Global file usage *Global template usage * Import pages (not the api, which can do this) Other special pages * Book sources
* Watchlist system
I'm not saying these aren't useful, in fact I bet a few would be used everywhere. So ship them in related-groups as extensions that come default-on. It really should be up to system admins if they want to keep them. It would also mean that for almost any given special page you always know which folder to go into. Why maintain two different places for special pages and their translations? Some of these I'd also love to see alternatives to, I'm sure a lot can be done GUI wise and if you want to use an alternative an admin might not want to keep the old one, and present a cohesive package to her users.
Chad also joked about making the parser an extension, and I'm no expert on it but given how much trouble WYSIWYG editors are having with our wiki syntax, I wouldn't mind being able to say "yeah sure this is a wiki from scratch, I'll accept the CKeditor syntax instead" and have one that works great (and has show source!) Especially if I could mark all current pages as using Parser A, and new pages or edits get converted to Parser B.
In the end I think what decorifing brings to the table is: * Freedom of choice through modular programming, creating an extremely strong plugin/extension system * Atomic entities that are easier to test independent of each other and translate * Able to transition from testing an alternative to making it the default seamless and almost risk-free. Think about it, if the default is an extension that is hooked in, it's trivial to ship an alternative "up and comer" alongside it for people to try, and if it becomes more attractive, you can just flip the switch and make it the new default. People who prefer the old can go back to it.
You maintain the idea of shipping a "complete" package to your users by bundling extensions (as Brion mentioned) and you foster and promote a very healthy contributing community by making the barrier to entry low and the rewards higher.
I'm very new to this community, and Brion seemed to indicate that this was already the plan, but that wasn't the story I was getting elsewhere. Nevertheless I apologise if I'm talking a little too loudly to the choir. I hope I can get up to speed on what's going on very quickly, by exploring the lists and documentation (you've got a decade's worth! please be patient), voicing my thoughts and questions.