Having a codebase compatible with both versions of SDL sounds sensible, but having spent a day considering it, I suspect it would be a mistake.
Compatibility is never going to be perfect, so in practice I expect that a lot of games will require "pygame 1.10 compiled with SDL 2" or "...with SDL 1.2", according to what the developer tested it with. The packaging systems I'm familiar with are not able to express a dependency like this. So it would be useful if the name (e.g. pygame2) or version (e.g. pygame version 2.0) of the package encoded that it was based on SDL 2.
To frame this another way: for most people there will be a sudden transition when the pre-compiled packages they use switch to building with SDL 2. If pygame makes releases that are compatible with both SDL versions, the packages from PyPI, conda, apt, homebrew and so on may make that transition at different version numbers, generating confusion. If pygame 2.0 simply switches to SDL 2, the switch is coordinated, so the version number is a reliable indicator of what you're getting.
So if we do turn the pygame codebase into an SDL 2 wrapper, rather than adopting/recommending one of the existing wrappers, I would strongly suggest that we a) make a clean switch, not attempting to support both, and b) use a new major version number, or even a new package name, to clearly distinguish it.