Generic framework stuff to handle situations like iTunes XML and external cue sheets.  The idea here is that some filetypes, on scan, provide additional metadata about other tracks (or create seemingly unrelated tracks).

Create a kitchen sink schema that encompasses most of current SC functionality.  This will probably be a lsow ongoing process, and will probably uncover lots of related subtasks.

Sort out UTF-8 all the way through the stack for tags and for pathnames (including SQLite - options here are binary data in SQLite with perl-level interpretation, compiling sqlite against ICU, or trying to make our own patched DBD::SQLite + libsqlite build that hooks in the existing perl unicode support via XS).

Switch to a generic unique persistent indentifier, generated in the base case from a hash of path/start/stop info, otherwise from musicbrainz, etc...

Search serialization

Multi-root (? some design questions remain here: how do we identify the roots of a multi-root library when hotplugged to new mountpoints on all platforms?  Writing a UUID to the directory root works, but not for R/O media) - I'm inclined to just not do this unless there's a good solution here.

cross-platform FS notify support, to feed triggers to the above (we would wrap it in this library, but ultimately the outer application (SC) would have to monitor the triggers via callbacks and call the async scan).  Win32::ReadDirectoryChangesW / Linux::Inotify / IO::KQueue (MacOS/X)

Allow MySQL Engine - probably let the user sort out getting mysql up and running, and add an argument to pass the mysql database name (or generate it and store it in db_path).  Could also go the "custom config" route and store the mysql database at the db_path, would make perms for CREATE DATABASE, etc easier anyways.