C is just riddled with mistakes and this one finally gelled with me. Python taught me that whitespace is great for syntax and, in this case, I'm quite convinced that it should be used more firmly in most languages.
Python's syntax precludes works against a lot of things, like first-class lambdas, case (yes it can be emulated with if/elif, but it's not the same, even without fallthrough), pattern-matching in general, or assigning the result of a method-chaining pipeline to a variable.
I use python at $dayjob, and I run into the limitations of whitespace as syntax all the time.
I think a better (subjective of course) lesson might be to enforce a style.
I have been thinking about making a toy compiler (I wanted to write a borrow checker) that treats bad code as an error, solely aimed at numerical code - I have recently had "Scientific Programming in Python for physics etc." inflicted on me.
Slight tangent, but I think if Haskell enforced some kind of whitespace a la Python it would be much more approachable in real codebases (Haskell is usually quite readable if you are just translating mathematics into code but it - to me at least - feels dreadful as a productive language because of the way a lot of functions seem to be dumped onto into the text editor in a lot of the code I have read)
Not really relevant to the broader discussion, but Haskell's whitespace sensitivity is defined in terms of automatic insertion of braces and semicolons, and you can write it that way instead if you want. A few people do write Haskell that way (SPJ maybe?) but the community is mostly united around using whitespace. That said, it's useful to know about the braces and semicolons if you're generating Haskell code, because that's often easier. Also occasionally at the GHCI prompt, where it will let you keep things on one line.
If I'm describing a hypothetical language, then I'm actually describing a hypothetical language where you wouldn't declare more than one variable per line.
It's been a long, long time since C required a programmer to declare his variables at the top, and best practice argues that you declare a variable as close to its use as possible. So, there really isn't the same case for multiple variables on one line, whereas it may have been a little more forgivable, once upon a time.
Moreover, when I was first learning C, I learned from an O'Reilly book by Steve Oualline. I remember him saying, when it came to operator precedence, that coding style that relied on the rules was a really bad idea. I think he said something like, "Multiplication and division come before addition and subtraction, and use parentheses for everything else."
My bottom line is C has a little too much "convenience" to it. (Granted, to my taste.) It goes back to my van Rossum comment. I'm against special cases and loosey-goosey stuff.