âI think there's (a lotâ?) of new non-backward compatible features? [multi windows, default hardware support, touch events, etc]. Are there other changes that were previously skipped because it wasn't backward compatible.
I don't think trying to come up with a backwards-incompatible version of pygame is the right way to go. Pygame is the sort of API that's taught in books meant to teach children how to program - I think it makes sense to avoid obsoleting that knowledge.
Similarly, people have a lot of time and code invested in pygame. Some of that code exposes the pygame API - for example, in Ren'Py, we expose pygame events to game code. I imagine other pygame-based libraries are similar.
It's also not terribly necessary. In pygame_sdl2, we were able to add support for SDL2 functionality without materially changing the pygame API. For example, take the pygame(_sdl2).display module:
We added a new Window class to that module to represent SDL2 windows. display.set_mode creates a Window instance that display.update and the other methods access - but you could call .update on a Window instead. At least in theory, old code works, while new code can take advantage of new features.
We did something similar with events - kept the existing events while adding new events such as application state and text input events. (The application has to opt into the latter with new functions in pygame_sdl2.key.) As long as code is written in a way to ignore unknown events and fields on events - which should always be the case, or pygame1 would have been unable to add anything - it should work.
We've added support for a lot of other SDL2 functionality in the same way. I'm pretty sure it should be possible to make a version of pygame that runs existing pygame code while exposing new features to new code - allowing people to exploit much of their existing knowledge.Â
Some other thoughts:
It's probably impossible to implement something compatible with pygame without compiling at least some C code. One problem is blend modes - many of the pygame blend modes, including the default alphablend mode, aren't in SDL2.
I'm a little skeptical of ffi-based approaches on mobile platforms - linking everything together seems more likely to work.