Wouldn't it be good to have Python 4.x next with all these workarounds cleaned up and with only one right pythonic way for parallel procesing? Surelly with a bit of backward compatibility sacrificed like 2 vs 3.
After 10 years, the 2to3 transition is still ongoing, and lots of companies will be dealing with python2 code for a long, long time. Breaking backward compatibility was a terrible decision. Breaking it again now that most libraries and open source projects have finally moved to python3 would be suicide.
Programming languages should take backward compatibility as one of their most important features, because of the hundreds of millions of lines of code already written and that would need to be changed and validated. This is especially true in a dynamic language where you can't even rely on the compiler to point out the issues.
Won't python2 be EOLed sometime in 2020? Is someone expected to pick up security maintaince after that?
For starters:
If you get rid of CPython's atomic operations on lists and other simple objects, lots of Python code would need more locks than it needs now.
If, on the other hand, you wish to keep those operations atomic, without the GIL that means introducing fine-grained locks on specific objects, which would worsen even single-threaded performance. Imagine taking a pthread mutex each time you append an item to every list or store a number in every variable.