gamebeater187 wrote:
Section 1: Is this topic rejected? (Short answer: No)

This suggestion is not a rejected suggestion. Keep in mind that a boolean block that reports true or false if a message has been received is rejected, because it has way too many problems. See this quote in the list of rejected suggestions:
Za-Chary wrote:
1.1 “Broadcast received” boolean block
The block below would allow a project to detect when a broadcast is sent. But, there is a lot of ambiguity on how this would work. Would it return true if the broadcast was fired since the project was created, since the green flag was clicked, or since something else was broadcasted? The workaround is simple: use variables that change when a broadcast is received, then use the “equals” block.

However, the blocks “repeat until broadcast received” and “wait until broadcast received” are NOT rejected; you can discuss them on this topic.

Section 2: What are you suggesting?
I am suggesting two new blocks:
repeat until [broadcast v]

end
wait until [broadcast v]
The first one repeats itself until that message is broadcasted.The second one waits until the message is broadcasted.
Because you can do
broadcast (join [] []) 
by dragging things into the broadcast dropdown menu, you should also be able to drag things into these new blocks too:
repeat until (join [] [])

end
wait until (join [] [])
If the broadcast doesn't exist, then the most obvious solution would to keep repeating indefinitely or waiting indefinitely.
But wait! Is there a workaround?
Yes! There is!
Section 3: But why add this block if there is a workaround?
Argument 1: The workaround isn't as simple as you think.
Any workaround involves variables. Variables are great. But in scratch, because of the block-building environment, too many variables can cause problems. It isn't fun scrolling through a large list of variables in a big and/or complex project just to get the right one. Message broadcasts are made to not have to do their workarounds, which will mean more variables. If message broadcasts are there to make the quality of life easier for scratchers who don't want to do these workarounds, then why not make them more useful?

I agree, it is a subjective statement whether to say “The workaround is simple”, or “The workaround is not simple”. Just understand that making a variable, scrolling to find the right variable, and placing multiple blocks isn't so good. A lot of blocks in Scratch are already workaroundable, and these blocks exist for quality-of-life improvements that save time.

This brings us to our next major argument,
Argument 2: Existing blocks have easier workarounds, or workarounds that take the same amount of time.
The forever block has the easiest workaround ever. And in fact, All message broadcasts have a similar workaround. Why just reject some block because of a workaround that isn't as simple to do?

Argument 3: The workaround can't do everything.
That's right, the workaround does not have the potential of these blocks. This means that there is something that the workaround can't do that these blocks can do.
What?
Let me explain, you can broadcast anything you want, but you can't create a variable. For example, the below block is completely possible:
broadcast (join [] [])
But you can't do this: (Excluding hacked blocks, I don't even know if this works anymore, but if it still does, this thing creates variables)
set (join [] []) to (join [] [])
Meaning if you want to have 1000 broadcasts (which can be useful), but don't want to create them by hand, you can just use this special broadcast block functionality to use. If you want the workaround, then you must create 1000 variables manually.

Sure, there may be a much more complex workaround involving lists or stuff like that, but then it gets too complex. There are existing blocks with complex or time consuming workarounds like
(length of [])
or even
repeat until <> 
end
, but such blocks have a very good reason to exist in Scratch. And so are these two blocks I am suggesting.

Some blocks are good such as

repeat until [broadcast v]

end

wait until [broadcast v]

However, some blocks like this one…

broadcast (join [][])

repeat until (join [][])

end

could contribute to project's bugs, since the without boolean, it will be impossible to “actually” run it if the single value is “true” (not a boolean like 2 = 2). Broadcasting a value can be confusing since we name the broadcast message names, what are they gonna do? Auto-create? Broadcast to nowhere? Or probably crash the project due to programming error?

I suggest when adding broadcasting values, you should include…

when I receive (join [][])

Am I wrong? Quote to me!