I don't have any doc on that (there used to be one at the old mirc.net, written by Ntd, but it no longer exists) but I'll try to explain myself what the [ ] are for (at least how I understand it).

The known (and fairly well documented) properties of [ ] are:

1) they control the order of evaluation
2) they can re-evaluate single variables/identifiers, like $eval(%var/$ident,2)

I'll give you a couple of examples on these before I go on with the other, more peculiar property of [ ].

1) To observe the order of evaluation, we'll use this alias:
Code:
print if !$0 { tokenize 32 1 } | echo 3 -a echo from print( $+ $1-) alias | return value of print( $+ $1-)
If you type
//echo -a $print(1) [ $print(2) ] $print(3)
you'll notice that $print(2) gets evaluated first. The [ ] can be nested too:
//echo -a $print(1) [ $print(2.1) $print(2.2) [ $print(2.3) ] ] $print(3)
$print(2.3) gets evaluated first

2) Their ability of [ ] to re-evaluate vars/idents is pretty straightforward. The only thing that you should remember is that it only works where there is only a single variable or identifier inside the [ ]. Example:
//echo -a [ [ $!version $!version ] ]
returns "$version $version"

//echo -a [ [ $!version ] ]
returns "6.12"


Now, the weird (and not clearly documented) part. The $+ identifier (NOT the $+(), which is newer) behaves in a totally different way when inside [ ]. In normal code, the order of evaluation in any expression v1 $+ v2is this:

1) v1 gets evaluated
2) v2 gets evaluated
3) the values of v1 and v2 are concatenated by $+

Again, we'll use the $print alias to observe this:
//echo -a $print(1) $+ $print(2)

Inside [ ] though, things are different. In any expression like the above

1) v1 gets evaluated
2) the value of v1 and the UNEVALUATED v2 are concatenated by $+
3) the resulting string gets evaluated

To observe this one, we'll use another alias:
Code:
alias p%test echo 5 -a echo from p%test | return value of p%test
The % char inside the alias name is deliberate (and perfectly accepted by mirc). Type this:
//var %test | echo -s [ foo $!p $+ %test bar ]
You get "foo <value of $p%test> bar". Let's examine it step by step:

1) v1 gets evaluated
v1 here is "$!p". When it's evaluated, the result is the string "$p"

2) the value of v1 and the UNEVALUATED v2 are concatenated by $+
"$p" is concatenated with "%test", which did NOT get evaluated (if it did, it would be $null)

3) the resulting string gets evaluated
the resulting string here is "$p%test", which gets evaluated


This behaviour is one of the reasons that the well-known %blah [ $+ [ %bleh ] ] method of retrieving dynamic variables works, although it may not be obvious at first. Let's analyze this example:
//var %blah32 = tada | echo -a %blah [ $+ [ $bits ] ]

Here, we have a case similar to [ v1 $+ v2 ], except that v1, which here is "%blah", is outside the outer [ ]. For this reason, v1 won't be evaluated first (like "$!p" did in the previous example); the outer [ ] gives priority to its contents. So step (1) is skipped. In step (2), v2 is $bits, but unlike "%test" from the previous example, it is enclosed in [ ] itself (nested brackets). So, "$bits" will not be left unevaluated (like "%test" did) prior to its concatenation with v1 (ie "%blah"). So, we have the string "%blah" concatenated with the value of $bits, which is 32. Finally, step (3), which is the evaluation of the resulting string "%blah32", follows. Tada!


/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com