I think this is a really good thing to think through.
The issues you bring up hinge on one thing (compatibility concerns). So far the unit tests pass. From my investigations, I haven't been able to find any theoretical reasons why it can't be compatible for 99% of things using pygame.
The stronger evidence of tests passing, and no concrete theoretical reasons presented on why it can't be compatible suggests to me that it can be done. As the patches currently exist, and have for some time, gives me a reason to think those fears about OS packagers doing strange things are unfounded. As they upgrade SDL versions at different times, I think we should still be ok if things are compatible.
By not aiming for compatibility we guarantee there won't be. Having a compatible pygame API lets us do that, and still release to places where SDL2 doesn't exist yet. If considering the API is compatible as I hope, then I don't see a problem with people who require SDL2 features seeing if they are running on an SDL2 pygame.
A pygame 2.0 would be released under the pygame package name, with SDL 2 as default, with a pygame compatible API. Until we get to that point pygame 1.10.0+ will exist, but patches and conditional compilation will be available for SDL2. (as they exist right now, but made easier to select). Old modules like cdrom, and overlay will be marked as depreciated.
By using new pygame APIs for differences between SDL1 and SDL2 we allow the old apps to continue working. So there should be no sudden break the world transition.
If an app really isn't compatible with a newer pygame for some reason (unlikely IMHO), then it's still possible for an older version to be bundled with pip, conda, and many virtual envs. Things like apt, could do like they did with SDL1, and python2 and python3. That is, making pygame1 into a pygame1-sdl1 package, which perhaps gets installed as pygame1. Then the rare cases of old uncompatible apps, which have not been updated themselves are covered. But I honestly don't think that will happen.