I absolutely agree 100% that it is not worth trying to fix the GIL for every conceivable situation (although if you could, I wouldn't complain).

To me, there are really only two scenarios worth worrying about:

1. Get rid of all of that multicore lock thrashing that happens if there are multiple CPU-bound threads competing.  Python programmers should know that intentionally using threads like this won't offer a performance boost.  However, it would still be nice to avoid all of that needless overhead when it happens by design or by accident (the new GIL already addresses this).

2. Make sure that you can get reasonable I/O performance when there is *one* CPU-bound thread competing with some background I/O processing.  This covers the use case of overlapped I/O and computation as well as almost every practical problem related to communicating processes, multiprocessing, queuing, etc. 

As for everything else, it's probably not worth worrying about so much.  If someone is only doing I/O (e.g., a web server), their code is going to behave about the same as before (although maybe slightly better under heavy load if there's less GIL contention).  Situations where someone intentionally tries to set up multiple long-running CPU-bound threads seems pretty unlikely---the very presence of the GIL wouldn't make that kind of programming model attractive in the first place, so why would they do it?