In case it helps, https://gist.github.com/757166 shows how to create a backwards-compat loader for 1.3. You could include a copy of the loader in django-admin-tools with instructions on how to add it to your settings if you are using 1.3. Hopefully a new version of the standalone staticfiles will come out soon that adds support for static/ by default.
Having implemented (and thought about) staticfiles a lot, I implore you to not ship a custom file finder with admin-tools. We try to standardize on one location for static app, similar to how the templates dirs work.
The reason to not move the admin/media directory around is simple and crude backwards compatibility -- many users have symlinked to this specific directory (myself included in older projects), which is why it'd be a major pain to upgrade.
One way of handling your issue is close to what @coderanger proposed: Move the files to static/ and tell the users on Django<1.3 to use the django-staticfiles app  instead of the contrib app. It has a setting (STATICFILES_MEDIA_DIRNAMES, ) that can be set to a list of directory names that should be searched, e.g. in your case ['media', 'static'].
But if you can wait a few days, I'm almost ready with a new release (0.4.X) of django-staticfiles, that will be compatible with Django 1.3's staticfiles and make the transition for 1.2.X users a lot smoother.
This app released as 1.0a1 is identical (mostly) to what will ship in Django 1.3 as django.contrib.staticfiles and can be used on older Django versions, too. I'd recommend using this in your docs since it'll make upgrading to Django 1.3+ much easier.
+1 on putting static files of each app in its 'static' subdirectory, as proposed by Anonymous above, just as how app templates are shipped with each app.
Jeffrey: thanks for taking time to address this issue, unfortunately I have some problems with the change:
MANIFEST.in and docs need to be updated to reflect the change
wouldn't it be better to go with the idea of a "static" directory inside of each app, like templates ? (as proposed by Anonymous and Jannis above)
the most important one: how can we make this change backwards compatible ? releasing it like this means it will break every installation that use the "symlink" approach to setup media files... I'm worried about that.
Regarding the symlinking, I guess you could ship the files in both media/ and static/ for a while and warn users about a future change. I wouldn't recommend symlinking the dirs to each other since distutils can't handle it (IIRC) and Windows support is more than spotty.
Alternatively, since symlinking seems to be an custom deployment step anyway, just warn users that the move happens in version X.Y and provide simple instructions to recreate the symlink.
Pointing users to django-staticfiles (for older versions of Django) or django.contrib.staticfiles would also be sensible, of course, since we really try to solve the static files problem at the source (Django) and make it easier for app authors. staticfiles' collectstatic management command also has a --link option for anyone relying on symlinks.
Sent a pull request. A suggestion to maintain the old "media" dir: Update all static files only in the static directories in each app. After that you can run ./manage.py using staticfiles to collect all files in the central ./media directory. This way you won't have to edit the files in two locations.
Hi - I'm not clear why the /media and /static folders now have different contents. I'm using 1.3 and static files, and manage.py collectstatic doesn't seem to grab everything it needs... some stuff still lives in the media directory (e.g. the css).
Is this still being cleaned up, or is the intention to properly duplicate the directories for a few releases?