From this description in the changelog:
Command-scoped Variable names that are prefixed with two '~' are considered command-shared. That means that the variable will be, 'shared' among commands that are executing in the same execution chain.
I infer part of the purpose(aside from simply reusing names) of command-scoped variables is to allow multiple independent commands to execute simultaneously, and be sure they do not interfere with each other even if they have the same local variable names.
If this is the intent, it could be considered an issue that when a command that has the "Allow other commands to be executed while this one is running" option enabled is executed while another instance of itself is already running, their local variables do interfere with each other.
For example, if you have a simple loop counting to 5:
Set small int (condition) [~LoopCount] value to 5
Start Loop While : [~LoopCount] Does Not Equal 0
Write '[Purple] {SMALL:~LoopCount}' to log
Set small int (condition) [~LoopCount] value as decremented by 1
Pause 0,5 seconds
End Loop
The output when running two instances becomes:
Shortcut : 'Basic repeat loop'
5
4
3
Shortcut : 'Basic repeat loop'
5
4
3
2
1
Where it is important to mention that as soon as the second instance is running, both instances take turns decrementing the value, so the loop finishes in half the time.
Now, I can't claim to have an application that requires two instances of the same command running simultaneously(certainly not one that requires keypresses, I would think), but I felt it worth mentioning in case this behavior may need to be described in the documentation somewhere.
EDIT: Solved in v1.6.1.10