We could also say that IN is an abbreviation for INSIDE and then if you're the sort who prefers to take the short name for variables then at least you won't have to invent your own longer name for accessing the operation.
That might split the difference.
Another Musing... Take BIND for Virtual Bind
BIND has mutated the bindings of blocks when you pass them, and traditionally Rebol makes the thing being modified the first argument. (See this discussion of parameter order)
IN was also mutating (though no longer). But it reversed the parameters so you could have a long block after a short context reference:
do in context [
this block
could be
very long
...
]
That looks better than using BIND's order:
do bind [
this block
could be
very long
...
] context ; "huh, what's this about" (have to scroll up to figure it out
If we rethought mutating BIND to be something else, then we could reorder BIND's parameters:
do bind context [
this block
could be
very long
...
]
This would make more sense for WORD!s, because all bindings of words are effectively "virtual" (binding a word does not impact the word you passed in--it can't because words are passed by value, not references like series are).
It doesn't look quite as coherent for testing if a word is "in" a context as IN did:
if bind context word [...]
if in context word [...] ; this does make a bit more sense
But maybe that's just a matter of how we've learned to think of BIND as being mutating. If we read that as "bind this context ONTO word" it might be okay.
I don't know what you'd call the mutating operation. bindify? contextualize? :-/
Anyway, just a thought I had to add to the mix...I'm not really convinced of anything yet, and the historical IN usage kind of looks the best...so I'm leaning to the IN+INSIDE middle ground.