Looking at this, I started to compare it to the & syntax that's been used in PARSE.
>> parse [2 4 6] [some &even?]
== 6
I haven't really warmed up to it very much.
So I wondered... what if PARSE used the trailing slash notation, assuming that meant run a function as a typechecker?
>> parse [2 4 6] [some even?/]
== 6
I find that more palatable than the leading-ampersand, for the reasons mentioned (looks better, and puts the slashy "barrier" at the end to semotically indicate "no parameters taken").
Though it doesn't have the generalization to other types:
>> parse [2 4 6 <eight>] [some &[even? tag!]]
== <eight>
But that could be done with a MATCHER combinator:
>> parse [2 4 6 <eight>] [some matcher [even? tag!]]
== <eight>
And arguably that's a lot more literate and less-symbol-y. It better bridges the non-PARSE code with the PARSE code. (Though MATCHER would take its argument literally, e.g. the BLOCK! you pass it like [even? tag!] isn't being processed by the block combinator. Such combinators are not that common--ANY is another example--but I think they should be allowed.)
When you put this together with the idea of types as antiforms, it might mean being able to reclaim the & symbol entirely for something else.