Refactoring Plans

The Plugin API has a separate page.

Smaller, Nearer-Term Changes

Remove or fix mb_artist_id tagging (which currently arbitrarily picks the first credit). A user mentioned that other taggers (Jaikoz and MediaMonkey) fill this field with a null-separated list of IDs, which seems much more useful.
Shrink the interface size of the metadata backend API by unifying ID lookups with string-based lookups. Currently, beets.autotag.hooks has four functions per that abstract DB lookups: _album_for_id, _track_for_id, _album_candidates, and _item_candidates. It would be nice to collapse this into just two functions, especially as we look at adding new (non-MB) backends via a plugin API.

Resolve some strange behavior w.r.t. album-level fields and the update command. When there's an item with an inconsistent item-level field (i.e., two different items in the album have different values for the same album-level field) that is not written by the autotagger, it will get clobbered back to the uniform value even after beet update. The effect is that just importing and then immediately running update shows changes! That's confusing. The importer should probably enforce that all album-level fields are uniform.
Strict typing and coercions for Item fields. library.py should specify the desired Python type of each Item field; when setting an attribute, the value should be converted to the given type (e.g., the string '0' becomes False when assigned). This will, for instance, make the modify command work correctly for non-string fields (see #323). Additionally, this will put an end to confusing None values, which would be coerced to a "null" value of the appropriate type, solving some weirdness with the update command. Currently, we're being saved by SQLite's weak typing, which does these coercions for us.
Find a way to simplify the user prompts in the importer. They're currently running the risk of becoming "alphabet soup" from the point of view of the user: the increasing number of choices has made it less obvious what should be done at each step.

Asynchronous import decisions. This is an idea due to martian on IRC. When importing, don't necessarily force a user's decision immediately. Importing is a multi-step process: add to library, look up in MB, make decisions, and copy/write files. This way, a fast process could index everything and then decisions could be made offline. Possibly using an alternate interface, maybe a GUI.
Experiment with a NoSQL-style database. Two good candidates include sqlitedict and sqlite3dbm (or, eventually, a LeveDB binding).
Experiment with adopting an ORM (SQLAlchemy?) to simplify the library code while maintaining our current schema.