There's something to that. Partly the goal is to "keep simple things simple," so we maintain the Scratch idea of BROADCAST as a way to let the receiver decide whether to handle a particular message. On the other hand, we want to teach OOP with sprites as objects, so ASK and TELL serve to send a message to a particular sprite. On the third hand, ASK and TELL aren't really orthodox OOP because instead of just sending a keyword, i.e., a text string, maybe along with some input data, and let the object decide how to handle that message, ASK and TELL let you put the method code in the caller; the orthodox OOP way is to use OF, which lets you call only the sprite-local blocks that are published by the callee.
Global variables for communication are a last resort, or maybe a first resort for people coming from Scratch who don't know any better way to do it, especially because Scratch doesn't have custom reporters.
About what happens where in the source code, the answer (official from Jens) is that when a ring is executed (as it is in the SET block in this example), it turns some code into a procedure, which remembers the context in which it's created, including things like local variables but also including the current sprite, the one that's evaluating the ring. So that's when the MOVE block becomes, in effect, a MOVE SPRITE1 block.
The OF block has the magic power to turn the procedure into a new procedure with the other sprite in its context.
@everybody: The reason I posted this is that in a conversation with Jens it turned out that I totally didn't understand this point. Jens convinced me that it's the right thing, but I told him that I'm pretty sure no users understand it that way. Users think the procedure is just its code, and when that fails, they move to a model in which a sprite is wired into the motion blocks in its palette. Seeing the ring as what does the binding of a block to a sprite nobody gets, except now the people following the thread.
So, I'm not arguing to change the model, which is really pretty elegant, but I think we should do something to make it more discoverable for users. I'm not yet sure what the something is, but my first thought is that if you look at the value of FOO, it should be
because that can be applied to any block without relying on English grammar that happens to work for MOVE.
I should add that it's my fault that the value reported by a gray ring, i.e., a procedure, is shown with a gray ring around it. Really it should be some different visualization, a purple ring or something, to clarify that it's a procedure value rather than a request to make a procedure. I thought one new notation (rings) was going to be hard enough for Scratchers, and we could live with the ambiguity.
stklos> (lambda (x) (+ x 3))
In Scheme (stklos is the dialect I have installed -- it's the least polluted by r6rs and r7rs), the result of running the lambda expression (which is what we represent with a gray ring) isn't a lambda expression, but rather a closure, which is the procedure text (the stuff in the lambda expression) combined with the environment (all the visible bindings of names to variable values). Most Scheme implementations, including stklos, don't try to display what's inside a closure, because environments are typically very heavily recursive data structures. (See SICP 3.1 and 3.2.)
P.S. I forgot one of the ways to do message passing: the BROADCAST block now optionally takes a particular sprite to be the receiver of the message. So the message is a keyword, rather than a block. This is the official correct (i.e., Smalltalk) way to do message passing. I think this capability is good to have, although using the name BROADCAST for it bothers me somewhat. (Media people these days talk about "narrowcasting" when they use what is generally a broadcast medium to send something only to selected viewers. That's a cute neologism but I wouldn't want us to use it!)
One reason we're adding this new kind of BROADCAST right now is that it works across scene changes, whereas trying to send code across scene changes is problematic (because the closures don't exist in the new scene).