We know what new refinements will do when you put them in a dialect like APPLY.:
call:shell // [ ; infix APPLY
[(system.options.boot) --suppress {"*"} print.reb 100]
:input 'none ; pipe input from /dev/null
:output data: {} ; write output to string
]
The :input and :output will be noticed literally by APPLY. But this doesn't prescribe any particular evaluator meaning for them when not dialected.
Old refinements (e.g. /input and /output) would evaluate to bound versions of themselves... so effectively synonyms for $/input and $/output.
(This makes me aware of a likely bug in the optimization of paths (chains) of this size... they use a WORD! cell format. Which means they only capture the binding of the specific word...while array-based sequences get a "whole specifier". It doesn't seem to me that the length of the sequence should affect what kind of environment it captures. e.g. [_ input] should capture the same amount of context as the path produced by it does...but if we forced embedded GROUP!s to be fixed in their biding on sequence creation that might be undesirable. Review.)
Anyway...we know that .input is evaluative (picking the field out of the "current coupled context"). And /input will be evaluative (calling a function). Then foo:bar will be evaluative, calling FOO with the refinement BAR.
So what of :foo? Due to what we want it to do in APPLY, we know that giving it any active meaning in the evaluator would be a bad idea. But maybe the best idea is to be conservative and error on it for now. That won't stop you from creating unbound forms (':foo) or bound forms ($:foo)...and discouraging its use as a generic inert form probably has advantages in other contexts besides helping APPLY.
If it turns out that having it act as a generic unbound version of itself has some great application, I'll reconsider. But error for now.