+1 on Media Manager improvements and simplification of Taxonomy table structures. I can’t exactly put my finger on what’s wrong with the Medial Manager, but it could definitely stand to be easier and prettier.
Meta-data for everything (taxonomies, media). I’d love to be able to tag my media with keywords, then be able to search on that (in the media manager, as well as front-end searches).
Taxonomies for users.
Generalize URL routing more, and give more control over URLs for things like authors, categories/tags, etc. Yes, resolving conflicts will require some thought and planning. But as long as rules are consistent, it should be fine. Current URL setup should be redone as a set of filterable regexp rules which can be overridden by themes/plugins.
Over time, at least for me, the Links Manager has become less and less important. Turn it into a Core Plugin, convert it to use custom post types, and ditch the old tables.
As mentioned recently on wp-hackers, an intuitive, documented method to bypass the default get_posts that happens in the normal wp initialization.
Clean up default user profile info (hard-coded services like AIM, Yahoo, Jabber/GTalk). These should probably be configurable in the backend somewhere, allowing the admin to create relevant entries? This might be Core Plugin territory.
Also, I’d like some helper functions that make it easier to add buttons to the editors (TinyMCE and Quicktags) for simple things like a ‘code’ HTML tag.
Lastly, I’d like to suggest a push in the Core Plugins area for “API-only” plugins, such as is often seen in the Drupal community. This is pretty developer-centric, but part of the notion behind Core Plugins is supposed to be to keep developers from having to reinvent the wheel over and over. Core Plugins which provide a common basis for other plugins to build upon, without providing much/anything in the way of front-end features make sense. Use-cases include things such as: OAuth; service specific APIs for Twitter, Facebook, Flickr, etc.; advanced hooks for media management…
Too lofty for a 3.2 goal, but eventually, I’d like to see more of the SQL stuff abstracted out to the point that it could be easier to use alternative database engines for some/all of WP core. Yes, it’s possible right now to create your own db.php, but that’s a bit of a sledgehammer, and there’s still some MySQL-specific features/syntax elsewhere in core. Eventually, what if a developer could choose to store user data in MongoDB? Or store posts in Redis?