Chiming in to add another vote of interest. I'm a maintainer of several packages with migrations and I'd like a non-hack way to support older Djangos along with 1.7. The South 2 solution is great where there is one set of migrations, native to Django 1.7 and usable via South 2 for older versions. But a new South 0.x is a fine solution too. Trey Hunner proposes a quite reasonable option where `south_migrations` coexist with `migrations`. All we need is a South 0.x that uses this scheme.
Telling upgraders that they must specify `SOUTH_MIGRATION_MODULES` in settings.py, while pretty painless, is a break of backward compatibility. Pip-requiring a new version of South is better. If the end user didn't want to update South, then they could still use the settings.py config.
Most of all, I'd like to avoid the situation of "choosing poorly" where I ship something that is incompatible with whatever solution South does implement.