$+ is triggering a "*break" error in several different ways, when $+ is the only non-space thing inside a parameter. The glitch can result in several different behaviors. It can cause the identifier to return $null when it normally never does that, or returns the other parameter(s) as literal text, or causes the *break error when anything arbitrary follows that identifier.

No error:
//unset %a | echo -a zero: $len(%a $+ ) and $len($null $+ )

Result is null:
//echo -a null: $len( $+ )
//echo -a null: $len($+)
//echo -a null: $sha1($+)

returns other parms as literal text:
//echo -a result is foo: $hash(foo,$+)
//echo -a result is foo1: $mid(foo,$+,1)

As happened in
https://forums.mirc.com/ubbthreads.php/topics/263957/hash-break-evaluation-error
arbitrary text following the identifier causes *break error:
//echo -a fail: $hash(foo,$+) bar
//echo -a fail: $len($+) foo
//echo -a fail: $len($+) $version
//var -s %b $null , %a foo $ $+ len($+ %b ) bar | write -c test.txt %a | echo -a fail: $read(test.txt,1)

//echo -a works $+($+ $& | )
//echo -a fails $+($+ $& | ) foo

doesn't always require text following the identifier to trigger *break:
//echo -a fail: $regex(foo,$len($+),0)
//echo -a fail: $left($+,1)

Using $+ swallows trailing text which touches it, without triggering an identifier warning. However, when it's inside [ brackets ], it instead triggers the *break error. Note that this $color(ctcp) *break error appears in the active @window, while the other cases always showed it to the status window.

//echo -ag null: foo $+abc bar
//echo -ag fail: foo [ $+abc ] bar

Well, this swallowing was not specific to $+ because other identifiers do it too if they end with parenthesis, so maybe that's as designed.

//echo -a $upper(foo)bar = FOO