That would have broken all C extensions, but it's not like Python 3 at launch was a raving success regarding library porting.
Fine grained locking works, but is expensive for non-multithreaded applications and slows down Python. It would speed up multithreaded applications though.
And they continued to break them within the py3k lifetime, mostly unicode related stuff from what I can remember. Probably still break stuff but I haven't had time for my toy python projects in a while so haven't been messing with the C-API lately.
I wished they had broken everything harder and once and for all, in order to fix the issue.
If there's going to be breakage anyway, people adjust their expectations. The scale is basically:
a lot of breakage > a bit of breakage >>>>>> no breakage.
Once you do break backwards compatibility, you might as well do it in a big way, provided you:
* don't offer vaporware for a decade (hello Perl 6!)
* try to offer some mitigations for the migration pain (auto-conversions, support libraries, top-notch docs, etc.)
* offer a great carrot at the end of the tunnel (good performance would be such a carrot)
Not for lack of trying. People have been trying to do this since at least python 1.4. They just haven't found a way of doing it without negatively affecting single threaded performance, which Guido considers an unacceptable trade-off. http://pyparallel.org is probably the most interesting latest experiment in this field, but it never got cross platform support and seems to have stalled out.