"Pascal" in this context seems to be "static typing with bounds checking" along with a handful of superficial syntactic similarities (but far more differences). You could substitute "Pascal" with a substantial subset of Algol-like languages and the comparison would make just as much (or little) sense.
As about bounds checking, unfortunately, there aren't many languages with dependent typing. (And Nimrod lacks them too.)
I mean, it's frustrating when a program suddenly fails at runtime. Especially when it can be proved at compile time that values won't (actually, can't) get out of bounds.
Lazarus and Free Pascal have been around for an age, likewise Delphi for even longer. And they're all still here. Pascal adoption may have slowed, but it has always been here and no "return" is necessary.
Wow, I knew about Lazarus but I didn't realize there were still new versions of Delphi coming out. Anyone used it recently?
Delphi got me my first paying programming jobs. I remember when later versions came bundled with Delphi 1.0 so you could still build 16-bit applications with it :)
Recent releases of Delphi have been troubled and a bit directionless; it seems like Embarcadero, the current owners, are understaffed or incapable, and they seem scattered and unable to make consistent strategic decisions.
In a world with maps and folds do new languages really need for-loops? They seem like putting goto into a language as a fallback for uncommon performance cases and people who don't have the hang of higher order functions.
In particular, I don't like the fact the for-loops are often used in first examples. I had that issue when I looked at tutorials for D and Go for the first time. My initial reaction was "Seriously?"
Loops have their place: in imperative languages, they allow you to very naturally express a series of instructions, which are of course what imperative languages are meant to express in the first place. By the same token, loops aren't really of much use in functional languages, if they're supported at all, unless the language also supports destructive update (and therefore has imperative features). One can debate the merits of imperative vs. functional programming, but there's no reason to avoid for-loops as a natural expression within the imperative paradigm.
One thing I like about python loops, which CoffeeScript and Ruby, and apparently Nimrod, have adopted as well, is that they make you iterate over a data structure, rather than the C-style of providing start, finish, and step. Iterating over a data structure provides a better guarantee that the loop will terminate without errors (whereas, in Java for example, you could fall off the end of a linked list or an array if you're not careful about your ending test or update step). This ends up being conceptually similar to a map, which is how Ruby's each method works anyway.
I don't know about D, but I don't think Go has map and other functional combinators, due to lack of generics. Besides, the world has had map and fold for a long time now, and this has not prevented for loops and iterators.
