Scratch is another solution for this problem
The transition path between them is indeed what you described.
It's a very cool initiative that helps make basic programming more accessible, and I value it as a way to show kids "hey, programming exists and can be fun!"
But I've also had the misfortune of running events where kids use Scratch. These were 7th-9th graders who self-selected in, so up to a decade older than the target audience in this article. The results aren't exactly pretty, and they don't make me optimistic about giving Scratch to 5 year olds.
Scratch seems to have two major problems: awkward control flow, and a gridless environment.
- The first comes through as a large fraction of programs having broken or absurd loop and branch logic - often with a clear plan in mind, but terrible results. The difficulty of establishing hidden state encourages all sorts of ugly practices like handling a health bar by nesting the same code three times in conditionals to handle taking damage.
- The second is that where SpriteBox uses grids to establish clear coordinate systems and touching/overlapping/separate states, Scratch uses a continuous field. It creates awkward and unintuitive collision results, adds a layer of unfriendly abstraction (what does "forward 200" actually mean?), and makes drag-and-drop initialization a touchy and miserable experience, even for adults.
Overall, I think Scratch succeeds at reducing text, but fails to make abstraction and control feel approachable. It also introduces lots of novel headaches not present even in 'real' programming.