Not 'script variables', the variables you get from right-clicking the block hat itself. The idea seems to be to turn blocks themselves into objects of their own.
Use this 'counter' block in a script, and the value increments by 10 each time you run the script. The first time, you get 1, 2, ..., 10, the second time, you get 11-20, etc.
If you duplicate this script, each one has a separate counter. But if you wrap it in a procedure of its own, and then use that procedure multiple times, there is still only one 'counter' block and they share the counter.
You wrap code in procedures when you want to reuse some code in multiple places, roughly speaking, but doing it shouldn't alter its behavior in this way, so this seems very wrong to me.
I don't see the problem here, why shouldn't it share the value?
I believe I made a test project with this a few years ago, I have since forgotten it's name and if I published it or not.
That's true (by definition) when you're doing functional programming, which doesn't depend on (or create) any saved state. But it's not true when you're doing old fashioned sequential programming, which is all about state. And in particular, OOP is all about saved local state, which is what a block variable gives you.
Even if your code interacts with mutable state, putting it in a procedure doesn't change what it does. And besides, block variables are very much more global state than local.
There's a library with a 'when changed' block that works most of the time, but if you have clones, it will only fire on one of them. Except if you make a clone permanent and disinherit its scripts, and then it will fire on that one too.
I think you are confusing scope with extent, another property of a variable. Scope means "where in the code is this variable visible?" Extent means "how long does this variable live?" In principle these properties are independent. (For example, consider plain old script variables. The extent of a script variable is the currently running invocation of the procedure -- unless the variable is captured in a lambda expression which is (or is part of) the procedure's return value, in which case it may live forever.) So, it's perfectly sensible that block variables have limited scope but infinite extent.
