It’d be easier to debug this if you posted a script pic rather than a screenshot!
It’s a documented restriction that the visual representation of a continuation includes only the nearby part, not the entire continuation out to the toplevel script. It’d be very hard to do that, and it doesn’t seem worth it.
Hmm, do you not know about script pics? If you right click on a script (such as the one in the picture) and choose “script pic,” what you get is a .png file which programs other than Snap! can display or print or whatever, but if you drag it into Snap!, the actual script will appear in the scripting area, with all needed custom blocks defined. (If you actually want Snap! to see the file as a picture, click on the Costumes tab before you drag it in.)
I’m not sure what’s going on here. Once upon a time there was a bug in Snap! that made creating a continuation fail if the attempt was in the last block of a script, so I instrumented your script a little and tried loading it into Snap! 8.1 (which I happen to have on my desktop for some reason I no longer remember) and (with those extra DO NOTHING blocks after the continuation is formed) it worked the way I’d expect your script to work. But when I load it into the current Snap! (which is a little tricky because you have to replace the old CALL W/CONTINUATION primitive with the version in the iteration library), it does the same thing it does for you. I’ll try looking at it again tomorrow and see if I’m any smarter. :~)
The key is that, because the continuation is being captured by a reporter, “set foo to {}” is expecting an input (normally given by the reporter, unless the continuation is run, in which case provided using inputs). If given none, the input is blank and foo is set to blank, causing the script to stop after running a second time.
PS: I’m not sure why your script in Snap 8 worked, @bh, can you provide it so I can do some tinkering of my own?