I have made a concept study for the “GLOBAL blocks” and create a project for this, to illustrate what I suggest.
https://scratch.mit.edu/projects/107734026

In this project I use a block with a complex script in other sprites. For this I pass the parameters to the GLOBAL_Block (GB) with local variables of the specific sprite. In the “Global area” for each sprite the process of the GB is protected through use a clone for this. Because each clone has it own local variables and so the process could run simultaneously without conflicts.
The only weak part is the use of the global variables. I try to use local variables and get the value with the <> of <> block in the GB but this do not work. After debugging I realize that this is not possible, because there is no way to specify the clone from which I will return the value of the variable.

My suggestions. A “Global Block” should only exits in a separate area (in my example: GLOBAL). A special sprite without motion, sound, look and pen blocks available. Pen? Is pen not global? No, because pen are related to stage and all script using pen could be placed in the backdrop area. What would happen if I use pen in the different clones of GLOBAL? This will make wild confusions and a lot of unwanted interactions.
Call the “global block” means to call an instance of the block only. And for the return to the sprites a special block

(GLOBAL [ v] of this sprite::sensing  )

should exist. This would give back the value of an local variables from Blocks in GLOBAL for each caller. And should deliver the calculated value only for this sprite e.g.:

SET speak for (%speakID) with (%speakRepl)
set [%text v] to (GLOBAL [speaktext v] for this sprite::sensing ) 

(this would the implementation of the variables like $BAT_speak in the workaround example. )

This is great!
I'll check the project later because i'm in my phone atm

I DONT KNOW YET