I'm proposing the addition of a default block within the “More Blocks” tab, much like the sprite property sensor, which gives you global access to custom blocks within specific sprites from anywhere in your project.

Once placed onto the canvas area, the block will automatically append the required parameters as defined by the user for the specified block

Building on this idea, and combining it with my other suggestion (read here: Handling Sprite and Clone Variables), we can also call custom blocks for specific clones

A somewhat related suggestion - it'd be great if custom blocks gave named field hints that go away once you click inside them. Currently, you either have to hunt down the definition to remember what the fields were, or resort to labeling every field and end up with a super long and clumsy custom block.

Unlike broadcasts, this allows you to not only call code from specific sprites (as opposed to the global nature of broadcasts), but also allows you to send parameters along with it. This allows for much cleaner code and lends itself closer to how one would organize a class structure in other languages; essentially treating sprites as classes, and custom blocks as their methods/interface.

The goal here is encapsulation; something that scratch only, well, scratches the surface on, but has tremendous potential for. One of Scratch's main goals is to learn by sharing/tinkering. In practice, although there are many mechanisms in place to encourage it, it can be quite difficult due to how tangled scratch code can become. The way I see it, encapsulation encourages true sharing. It allows users to take pieces and use them in their own projects without getting lost in spaghetti code. Publicly accessible custom blocks allows for programs to interface with encapsulated code in a non-destructive fashion.

when this sprite clicked