I'd add this to the direction Shai's comment is going (if i've interpreted Shai's commments correctly);
Some Django components (such as how static files are served) often change during the production life of a project; the way you auth users almost never changes, or if it does, it changes once.
This leads to the conclusion that an auth library that provides more than one type of auth is counter productive - if your auth library provides auth mechanisms A, B, C and D, and D has a bug that needs fixing, all users who only use A B or C need to also upgrade your library (or at least need to review the changes to determine they actually *dont* need to upgrade).
The gains from being able to switch from D to [A B or C] and still use the same library are almost non-existent. Even if switching doesn't require "pip install [alternative auth library], it *will* require a code review because of how different each auth mechanism is.
So even if you were to come up with a significantly better A, B, C or D library than the current options, your chances of getting it accepted into regular community use are much better if they are separate libraries.
This doesn't mean its not a worthwhile project or GSOC proposal, its just a fact of software design and planning.
D