(This is a feature request.)

Since the introduction of custom blocks in Scratch 2.0, "run without screen refresh" custom blocks have had a strange "edge case" behavior revealing awkward internals of the Scratch programming language. It's easy to demonstrate, as in the below script:

Try replicating this and running the project. You'll see the project runs extremely sluggishly; Scratch is normally supposed to run at 30 frames per second, but here it runs at only 1 frame per 500ms! After 10 frames (= 5s), the loop completes, and the sprite says "done".

I believe it's fairly safe to say that replacing this odd behavior with a more useful feature would not harm any backwards compatibility, because theoretically zero projects depend on this arbitrary behavior.

So, the proposal: Receiver scripts across all targets (stage/sprites/clones) should be found and then run to completion instantaneously, returning execution to the custom block within the same frame.

Arguments for this:

• It's compatible. Like mentioned, no project should depend on the arbitrary existing behavior!
• It's intuitive, at least in contrast to the existing behavior: why SHOULD this "broadcast and wait" cause such a long delay? There is a logical answer, but it requires an understanding of the Scratch internal codebase, and that isn't useful education for learners!
• It's educational. Learners will often find out (or be taught) about the broadcast blocks, which enable communication between sprites, clones, and the stage. For programmers with experience outside of Scratch, it's easy to draw connections to object oriented programming: communication across objects is the foundations of OOP! However, Scratch is limited in practical applications of this style of OOP, because currently, all cross-sprite communication requires waiting one frame. This prevents learners from really making use of their new knowledge, at least until they move to languages beyond Scratch.

Arguments against:

• It may take some time to implement. Wouldn't be a high priority issue if dev team members are busy.
• It's niche. However, maybe not so much as I'll argue below. (And a niche added feature has much less risk of community confusion or added requests than a big one.)

Finally, I'll say I believe this suggestion to be in the spirit of the existing Scratch language design, because Scratch provides low-level tools, such as clones, variables, and lists, which users may develop more powerful abstractions on top of, such as first class lists/sprites, pointers, and dictionaries. Largely, Scratch does not put arbitrary obstacles in front of this: the basic concepts it provides are very powerful, after all!

However, the current behavior is not only confusing and altogether impractical, it is also limiting. It could be replaced with a much more powerful (albeit very simple!) behavior, and this would enable Scratchers to create all kinds of interactions between sprites, rather than being forced to either wait one frame (not good for most complex programs, let alone games that require fast sprite interaction) or simply not communicate between sprites at all (relegating all data to lists, which is its own powerful abstraction, but it is no good to lock a learning coder into one programming style instead of giving them the options to explore).

Like I said, this is a niche request, so I wouldn't expect it to be prioritized! However, if it were discussed within the team and were given the green light, I'd be happy to have a go at implementing it. (I don't think it would be too complicated to put together, honestly.) It could be a really powerful addition to the language, without doing anything to overcomplicate Scratch's design - only giving the user more options to explore as they learn and experiment.