I'm not surprised that ^:_ might only be recognized as a special form. Having said that, using conceptually equivalent ways of supplying _ as an operand to (^:) --- through a gerund operand or the constant verb (_:) --- gives a buggy result:
2 -^:_]1 NB. (2-...-2-2-1) = 1
1
2 -^:(]`1:) _ NB. gerund equivalent
# 2 -^:(]`1:) _ NB. ??? no count
10+ 2 -^:(]`1:) _
a=: 2 -^:(]`1:) _ NB. error on assignment
|domain error
| a=:2 -^:(]`1:)_
Similar results here:
+/@]^:_] i.4 5
190 _ +/@]^:([`]) i.4 5
# _ +/@]^:([`[`]) i.4 5
a=:$_ +/@]^:([`[`]) i.4 5
|domain error
| a=:$_ +/@]^:([`[`])i.4 5
Some cases instead error on execution of the 'u' operand:
2 ^^:_]1 NB. as expected...
_
2 ^^:(]`1:) _ NB. error from ^ rather than from ^:
|domain error, executing dyad ^ echo@'hi'^:1:^:_.] 0 NB. echo 'hi' forever
hi
hi
hi
...
_. echo@'hi'^:1:^:([`]) 0 NB. a gerund equivalent; error from 'u'
|domain error, executing monad 1!:2&2
| _. echo@'hi'^:1:^:([`])0
If _: were explicitly disallowed as the 'n' operand, I'd expect an error from either the (^:) conjunction itself, or from the derived verb, as in the following cases:
3:^:_.]0 NB. attempt to use f^:_. outside of u^:v^:_. structure
|domain error, executing conj ^:
| 3: ^:_.]0
2 ^^:(]`1:) _. NB. attempt to use f^:_. outside of u^:v^:_. structure
|domain error, executing dyad ^^:(;:']1:')
| 2 ^^:(]`1:)_.
3:^:__: 0 NB. [negative infinity] constant verb
|domain error, executing monad 3:^:__
| 3:^:__:0