I'm 99.9% sure you won't be able to (and shouldn't be able to) redefine the @ SIGIL! behavior in the evaluator.
Historically I've had a lot of trouble with allowing any slash forms to be WORD!, but people very badly want / to be division in the main evaluator.
I wanted it to be a PATH!
>> to path! [_ _]
== /
...because I think Rebol completely sucks for math--and rarely do any in it--I felt like the inconsistency of needing to block these exception words from winding up in paths or tuples was a pain.
But that ship has sailed, really. Things like < or > need to be WORD!, and </> is a TAG!, so to path! [< >] has to know to fail. Might as well accept the slashy words and the checking that has to be done. (Paths are immutable and have a moment at creation time to do the check for illegal words.)
So I imagine // and /// etc. will be WORD!s and you could do this if you wanted.
(It is likely that . and .. and ... etc. will follow the same pattern and be WORD!)
The principal problem with this is that it makes for some annoying edge cases.
>> compose (void)/1
== /1
>> type of compose (void)/1
== &[path]
>> compose (void)/(void)
== /
>> type of compose (void)/(void)
== &[word]
You either do something weird when you get to these reduced cases, or you error. 