With the coming of modal arguments, it seems to me that:
append data @ some expression
Might be cleaner than:
append data @(some expression)
(Although append data @item or append data @[bl o ck] seems tighter than append data @ item or append data @ [bl o ck])
While it may not be fully necessary, it seems that if a lone @ were legal it would be worth it to allow so you could skip the parentheses. Which raises the question of what these odd lexical pieces should be standalone.
For an example of the kind of thinking that came in as precedent, Rebol2 considered # to be an empty-string-issue!:
rebol2>> type? #
== issue!
rebol2>> to string! #
== ""
When ISSUE! became an ANY-WORD! type in R3-Alpha, empty words were not legal. So there was a little-known choice to make # mean NONE!
r3-alpha>> #
== none ; actually #[none]
I think if this idea were going to catch on, then it should have been the actual rendering for NONE! literals. Which I did come to believe needed a single-character representation, but I think _ is a lot better than #, and BLANK! has been a pretty good name.
Other exceptions have made these things WORD!s, e.g. the historical choice to make / a WORD! exemption. I'm not a huge fan of that one due to the bad combination with pathing, and I think we're better off making PATH! a more ergonomic generalized part, and push the burden of figuring out how to make a 2-element path with BLANK! and BLANK! do division by putting that on the evaluator.
But if @ was a WORD! that would be a bit disruptive to the mechanics of things like modal arguments, if you wanted a normal evaluation that became modal after it. Because if people can say @: 12, then what if someone had meant append data @ and want to add 12 to it? Having it be a distinct type that can't have evaluator behavior override would make it more comfortable to use for this purpose.
If it can't be an "empty" "SYM-WORD!/LIT-WORD!", what should it be? A LIT!, SYM!, n AT! ?
Similar questions for what a lone colon could be exist too. The non-overrideable nature of making these a separate datatype are appealing. Anyone have strongly held opinions?