Thanks.
When defining the variable I could omit the trailing @ but not but not for the inline use of it. There may be instances where the variable is used in a way that doesn't word break.
At this point I don't feel comfortable refactoring the script/command engine because I don't want to accidentally change a behavior of how something currently works. I have quite a few test cases however I know that it doesn't cover everything and it would be very easy for something to break and go unnoticed. such as the issue with the command execution order.
My main goal is to make it as usable as possible without limitations and while I understand that this syntax might overly complicate the logic it does seem to work in many conditions where any way else could possibly fail.
I found an issue with the new variable code, if you assign a command to a variable such as /select it doesn't perform the command after replacing the variable with the value.
i.e. this doesn't execute the /select command.
Code:
/set @A@ /select -f *.txt
@A@