Python itself doesn't really need the whitespace, they syntax enforcement is for the users.
Hmm, well try un-indenting your Python code and see how your if statements pan out.
Compile-time type-checking is now optionally available for those few projects that need it. Books have been written on whether compile-time type-checking brings any advantages over memory optimisation.
Welcome to the 1960s. Been there, done that.
The 2 to 3 schism is now largely over. Most new projects are using Python 3, 3.5+ finally brings tangible improvements, 2.7 will be maintained until at least 2020. Projects can coexist for 2 and 3 with fairly minimal changes. That said, it's an investment with no immediate return for many older libraries. But rinse and repeat the discussion for any major release in any popular language.
It should never have happened in the first place. It was always going to cause problems, those problems arose immediately, and they're still annoying today. And given that there's a shit load of code written in 2.7 (large chunks of a lot of Linux distros, for example), are we seriously saying that it is OK to risk all that falling prey to security vulnerabilities after 2020 unless it is re-written for Python 3? Python might have language features that make a programmer efficient, but making them write, review, test, release, deploy and support their code twice simply because some language theoretician got all excited about a new way of expressing themselves in Python makes them much less efficient. And error prone.
AFAIK no other language has cut off source code bases written in previous versions of the language. For example, K&R C will still compile, just like it always did, possibly requiring a compiler switch to say it's OK.
Face it, you're a grumpy old git who resents the success that many people have because of Python.
Smirk. I've seen plenty of people get into deep, deep trouble with Python chasing idiotic bugs long after deployment that weren't picked up in development, simply because Python brings no certainty to what's going to happen when your code runs.
All the so called "improvements" you've outlined in your post (hints of type checking, resolving the schism, etc) are simply acknowledging that the things being "improved" represent a litany of errors made by those in control of the Python language. It's like they've experimented with radical ideas, and then slowly understood why others didn't do them first. Next thing we know Python will add curly braces.
As it happens there's a lot I think that Python has got right, it's a useful language. I like the multiprocessing, list comprehension, string handling, etc. But the pitfalls are too problematic for it to be taken seriously as a major language. Plus it's dog slow, unless relying on a shit load of compiled wheels, or pips, or whatever (usually they're written in C). Just how pythonic is it to rely on code written in C.
Also there's the mad, lunatic idea of having a package manager as part of the language installation that is independent of all the OS-provided package managers and makes massive assumptions about what sort of C/C++ build chain is present. It makes deploying Python application highly painful. It's fine for the enthusiastic dev who has root privileges, owns their own box, etc, but useless elsewhere.
Plus there's the issue of the fact that Python is not quite the same on different platforms; Python on Linux does some things subtly differently to Python on Windows. To make for totally reliable Python the dev has to be on top of what all these differences are and code around them as required. Of course, no one actually does.
I'll be sticking to my C, C++, C#.