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.
