I've definitely read that particular link and thought hard about how SICP should be written for a live coding environment. I don't think either the original SICP or Bret Victor will be the last word on this matter.

In Bret Victor's terms, the scheme used in SICP has very little "vocabulary" to learn to read. The first section (which I linked) uses only arithmetic functions and `if` to teach you, well, how to program. And the "show flow" examples emphasize mutation of variables through time, while scheme uses recursion in place of loops. I think something that shows the function calls explicitly would be good, or at least something that shows the flow of function call (like the DrRacket debugger).

At the risk of generalizing, Bret Victor deals with things like graphics, animations and simulations, while SICP treats programming like a branch of pure math, and it's not straightforward reconciling the two.

I'd love to talk more about this with you though!

Yes, the specific example scenarios that Victor has used are hard to directly reconcile with what SICP is doing. But, that the examples are oriented towards graphics and animation has only to do with the fact that the immediate target of his critique in the essay is Processing and a particular live coding implementation of it. I was thinking more in terms of applying the principles of learnability that he has put forward, and are manifest in the examples he has cited (Logo, Smalltalk, etc.), "how exactly" admittedly being an open question.

One thing I'm more or less certain about is that it would entail less live coding, and more stepping through visualized execution states (perhaps similar to pythontutor.com's visualizer).

I will be going through SICP with these in mind in the following weeks/months; I will keep you posted if I end up with notes that I think you might find useful.