Scratch Custom Block Mapping Causes Name and Input Type Conflicts

[Titanium2099]

When you create a new block named CUSTOM_BLOCK (INPUT 1) and then define another block called CUSTOM_BLOCK (INPUT 2), the first block definition becomes obsolete. Regardless of which instance of the block you use, the second one is always executed.

This happens because, internally, Scratch maps custom blocks to a generic identifier: CUSTOM_BLOCK %s (for block 1) and CUSTOM_BLOCK %s (for block 2), where %s represents an input (and %b represents a boolean). Since both blocks share the same mapping, Scratch cannot distinguish between them, leading it to always execute the most recently defined version.

There are two possible solutions:

1. Modify scratch-blocks to correctly recognize and obey the internal custom block ID. (Each block currently does have a unique internal ID, it just not being used (you can actually successfully parse a custom block into the editor without specifying its id at all)).
2. (Probably easier) Prevent users from creating custom blocks that would result in duplicate mappings with an existing block.