It doesn't handle the "true" debugging discussed in the article. One of the goals of the author is to move away from stepping through breakpoints and print statements to watch data "flow" through a program.
With debugging, we'll get there. I have some prototypes, but it's a long way from a research prototype to production, and we're still quite busy on getting actual products out the door.
And even at the moment, the fact that so much of a typical program in the Wolfram Language is referentially transparent means its easy to pick something up out of your codebase and mess around with it, then put it back. That's a huge win over procedural languages.
But in terms of the language, many of the ideas Chris is talking about are already possible (and common) in the Wolfram Language:
It's functional and symbolic, so programs are all about applying transformations to data. In fact, the entire language is 'data', with the interesting side effect that some 'data' evaluates and rewrites itself (e.g. If).
The mathematical sum notation is unsurprisingly straightforward in WL.
And StandardForm downvalues allow for arbitrary visual display of objects in the frontend.
For example, the card would have a symbolic representation like PlayingCard["Spade", 1], but you could write
