I dont think its got to do with evaluation brackets at all, its something in the nature of how /VAR is really /SET -l and infact calls SET over and over once for each variable.
The problem/bug appears to be in generating the variable name before the = , if it needs to be evaluated from parts, then the = sign is appended to the transfer of value data to the /SET command, and also there is incorrect/squewered logic in identifying the end of the value data, this might have been a simple look for the next ",%" or it might be more complexe to avoid other hidden traps we dont see becuase of the way it currently does it.
Examples below assume the follwoing...
%anothervar value is 1
alias SET { echo -a >SET $1- | set $1- }
ex simply showing how /var calls /set multiple times each with a -l option for local value
//var -s %a = 1,%b = 2
>SET -ls %a 1
* Set %a to 1
>SET -ls %b 2
* Set %b to 2
ex shows the problem as it appears
//var -s %somevar- $+ $me = $rand(1,%anothervar)
* Invalid format: $rand
ex shows the problem as it is, by stopping the evaluation of the $rand, we can see the %anothervar) is considered a variable name being set, also note the inclusion of the = sign into the first variable which is also an unwanted effect
//var -s %somevar- $+ $me = $!rand(1,%anothervar)
>SET -ls %somevar-DaveC = $rand(1
* Set %somevar-DaveC to = $rand(1
>SET -ls %anothervar)
* Set %anothervar) to
ex showing how to force the evaluation of the %anothervar first, this however doesnt fix the = sign being passed
//var -s %somevar- $+ $me = $rand(1, [ %anothervar ] )
>SET -ls %somevar-DaveC = 1
* Set %somevar-DaveC to = 1
ex accompaning the above ex to show where the "1" value was generated from
//var -s %somevar- $+ $me = $!rand(1, [ %anothervar ] )
>SET -ls %somevar-DaveC = $rand(1, 1 )
* Set %somevar-DaveC to = $rand(1, 1 )
Now all this being said, I would ask a question here as to WHY do you need DYNAMIC NAMED local vars, can you actually give an example of where one might been needed?
