The Swift Progamming Language...

[Linde]

1. Type Safety vs. Type Inference

I don't think you can have it both ways.
Inference makes it easier on the programmer, but also allows subtle bugs to creep in.
Did some work recently in RUBY where this became an issue.

Or maybe I have just spent too long programming in VHDL

I think that you are getting some concepts mixed up. Type inference won't necessarily cause subtle bugs. In Swift (like Go and I guess C#) the types are inferred at compile time, and if there is a type error (e.g. assigning a floating point number to a variable that was inferred to be an integer), the compiler will bail out to tell you. I believe that the problem you are thinking of relates to dynamically typed languages, where the type isn't necessarily known at runtime, such as ruby or python.

Python feels dated... Compared to C... For me, everything feels dated compared to C (and C derived languages, including Jave).

I'm not sure what definition of "dated" you assume here, but it obviously isn't the literal meaning of the word. What exactly make these languages feel dated compared to C? Do they remind you of any pre-C programming languages in particular? IMO Python has plenty of drawbacks that you can validly criticize, but I don't think this is one.

[Linde]

Python feels dated because it's such a throwback - an interpreted, dynamically-typed language where whitespace counts as part of the syntax?

All valid concerns, but I'm not sure how they contribute to your argument that it feels "dated". These perks have their pros and cons, and while the concepts aren't all exactly new, there is nothing fundamentally archaic about any of them. Since we're comparing to C, why not talk about digraphs and trigraphs?

A language where each version is subtly incompatible, so you may wind up needing several different installs of the runtime on the same computer?

Each version? Nope. Compatibility differences potentially exist between minor and major version numbers, but they are all well documented and far from subtle. If anything, I'll argue that the fact that the language is being actively maintained speaks for its "non-datedness", at least in the literal sense of the word. Not to say that the whole deal with python 2/3 isn't an awful mess, but again, it doesn't really contribute to your argument that it feels dated, unless you subscribe to some esoteric idea of what feels dated that doesn't have anything to do with contemporary ideas and expectations or continuity.

It's like a little piece of the '80s and their semi-infinite number of bizarre one-off language variants for one particular brand of home computer somehow bubbled up into the present and accreted elements from newer trends.

I think you'll have to be more specific. You aren't really saying anything substantial about Python or any of the anonymous 80's home computer language variants you are presumably comparing it to.

It also feels dated because it's taken up Visual Basic's mantle as "the quick-and-easy programming language everybody uses to hack up small utility programs so you inevitably have to go to an entirely different website and download another program in order to run the program you just downloaded" - at least where .NET hasn't filled that role.

You are not making a valid point about the language itself. Your criticism is first of all based on the presumption that software is written for its users to be downloaded. From that limited perspective, I may agree with you  (although I haven't been using operating systems that didn't come bundled with python 2.7.x for the past few years), but even then I question it as an argument against Python as a language, and most of all, for Python as a "dated" language.