Scratch

This idea has been suggested in several previous threads.  It would certainly be a useful addition to the language, but implementing it with clean semantics is not as easy as it looks,

beny, no that's not the problem.  Scratch already has both true/false and numeric expressions without causing confusion for most users.

one problem is figuring out what to do with a message if it doesn't immediately start scripts. Do you record that the message has been received so that you can test it later in a repeat-until?  That is, does "repeat x until I receive y" mean that if message y is broadcast while x is running, then the repeat loop is left?  Or does it mean that receiving y stops x in the middle of running and immediately goes to the code after the loop?

It is possible to come up with several different semantics (meanings for the blocks), and making sure that they will behave in a reasonable way is not trivial.

The current semantics is that broadcasting a message y starts all scripts that have a "when I receive y" hat---even if they are already in the middle of running.  That semantics can, I believe, be consistently extended to tests in waits and repeat-untils, but I'm not sure how to extend it to if-then-else tests.

Sorry, the discussions on this forum are so reasonable that I sometimes forget how young most of the readers are, and I end up using technical terms that most of the readers can't be expected to know.

"Semantics" is the study of meanings of sentences.  It is used in computer science to refer to the exact definitions of what program statements do.

The problem with doing a test for "I receive <message>" is to figure out exactly what that means in all places where one might put the block.  The broadcast messages now have a very simple meaning:  all scripts that have "when I receive" hats for that message are scheduled to start, no matter whether they are currently running or not.

It is very easy to generalize that meaning for messages to handle
   wait for <I receive message>
blocks, since all that would be needed would be to schedule scripts that were waiting to continue (rather than starting from the beginning).

Slightly more complicated is
   repeat
        ...
   until <I receive message>
since that would require marking the script when you enter the repeat so that the message would cause the script to stop, then continue after the until block.

Much more difficult is figuring out a reasonable way to handle
if <I receive message>
   do something
else
   do something else

The only ways I see that the if-then-else could be handled require a major change to the underlying meaning and implementation of messages, so that there is some memory of what messages have been sent.  One way would be to have a (hidden) variable for each such test.  When a message is sent, the variable gets set.  When the test is done the variable gets reset. 

But if this meaning were implemented for all the tests, it would give different behavior to "wait until I receive message" and "repeat until I receive message".  The wait would not wait at all if the message had been sent earlier, and the repeat would always do full passes through the body of the block.  I like the change this would make to repeat..until, but not the change it would make to "wait".

If we keep this meaning of "I receive message", we can fix the wait by having it mean
    clear the variable for this test
    wait until the variable for this test is set

Note: it is important that each test of "I receive message" has a different variable, not just one variable per message.

I think that "I receive message" can be made to have a consistent, clear meaning, but it would require changing the current meaning somewhat.

I don't know if I have made things clearer or muddier for you, Kingoflego, but I hope that I have made the meaning I want the new block to have clear to the Scratch team.

There are many blocks in scratch already that could be implemented in terms of simpler more basic blocks.  For example, all the movement blocks could be reduced to just
set x to <> and set y to <>.  That doesn't mean that the other movement blocks are useless---they help make code simpler and easier to read and write.

The same idea is behind the requests for <I receive message> tests.  It isn't that there is no other way to accomplish the effects, but that code will be simpler and more understandable if this feature is added to the language.