That's not quite good enough - people use threads to e.g. permit multiple blocking i/o operations to be in flight at once, which works perfectly well right now.

That's not quite good enough - people use threads to e.g. permit multiple blocking i/o operations to be in flight at once, which works perfectly well right now. So you're going to want to support multiple GIL threads if you want to be able to support existing code safely. Sadly, you can't just trivially bolt on thread safety to code that was not designed with it in mind. However, if you go the other way and introduce e.g. an @nogil decorator, similar to that seen in some cpython alternatives, people will have a straightforward path to opt in incrementally as they fix and verify the critical parts of their code, while preserving known working behaviour elsewhere without having to throw entire complex systems over the wall at once.