One might think it obvious that an ordinary function that quotes its first argument needs to "win" when it quotes right... even if an enfix function after it quotes left. Because you want help -> to give you the help for ->, and not try to construct a function with the named parameter help (and then fail, due to having no body).
It's not quite that simple. To cut to the core of why not, consider the following from the evaluator's point of view:
(print "message", 'lib)/help ->
Let's pretend for a moment that the evaluator gives the left hand side first dibs if it quotes its first argument. In that world, if the left is looked up and doesn't quote the right, then the right hand side gets second dibs...and is checked if it quotes its left argument.
But notice that to get the knowledge of if left-quotes-right or not, you have to evaluate that path. That can do processing which has costs you might not want... and groups can have side-effects (like the printing of the message). But since enfix dispatches from words only, it doesn't have that problem; it can be checked "cheaply" with no side-effects, making what the right hand side wants of the left a good fit for the first thing to check...falling through to the expensive operation with side-effects that you then know wins.
So that's why I've been letting right quoting over left win. But you might ask: how can HELP work without making you say help '-> (which might lead down the road of consistency and making you type help 'append) ? Because there's been a rule: "Right operators that quote left get priority, BUT become inert if they have nothing following them."
help -> ; gives you the help for lambda
help -> [print ["argument is" help]] ; gives you an arity-1 function
Weird, but it seemed to work well enough.
Reviewing it now, it's somewhat limiting. It means you can't have postfix operations that quote their left hand sides and take non-inert items on their left. But the alternative would mean never being able to left-quote paths, or having dodgy properties when you do. Hm.
Can It Be Narrower?
Might only "common quoting" :left escapable parameters have this loophole, with "I really want to quote it" operators being presumed rare enough to break HELP...and still run at end?
That sounds nice, but the "I really want to quote it" forms aren't going to be so rare. Remember that we want:
>> integer! = type of 1
== #[true]
This means the left can't be :property and deferent to enfix, which would let integer! = type run first (the way branches are deferent, to support lambdas). I was proposing it be ':property as a distinction, to say it's escapable -but- on only one unit of value.
So now we're back to what help of would do. We could argue that in this case, OF could sense that it's at the end...but doesn't have an endable next parameter...and it is the incompleteness that drives it to be deferent vs. error. However, maybe it would win if it didn't take any arguments, and that would be acceptable...?
Let's make a sample postfix non-deferent operation. Remember that in this model, HELP takes an escapable argument (at least :topic, possibly ':topic)
>> ?: enfixed func [':left] [print ["is" if not :left ["not"] "truthy"]]
>> _ ?
is not truthy
>> help ?
is truthy
>> help :('?) ; generic escapability (help gets the WORD! `?`)
? is an ACTION!
...help text here...
>> help :? ; also generic escapability (help gets the ACTION!)
? is an ACTION! ; and ACTION! now carries labels, so it can know the "?"
...help text here...
>> help '? ; unescaped, HELP gets QUOTED! (`'?`)
? is an ACTION! ; maybe HELP does the unquote internally, to give the answeer?
...help text here...
To me, this seems to give a number of options to someone who wants to get HELP on a left quoting enfix operation. Enough options to not make left-quoting enfix of words and paths impossible.
And how bad would this be, really? If we narrowed it down to where the only operators that require escaping to get HELP are those that are genuinely postfix hard-or-medium-quoting with no arguments... that's a pretty small set. To date, we have ZERO such operators in the box, they only exist in tests.
(e.g. OF quotes, but still needs another argument, so that would drive its deference so that help of would dispatch to HELP with OF as the parameter...while help of 10 would dispatch to OF with 'help as the property and 10 as the value)
This is important!
Having these things work out is the point, because this is what the unique offering is. These issues all lock together on foundational questions e.g. those pointed out by "speaking with tics".
When left-quoting enfix operators can subvert a quote from the right, that means when you say for-each x you can't be sure that X won't act on the FOR-EACH. But we can see that as different rom the situation type of is in...since OF gets the first shot.
Does that suggest the "out-of-the-box" constructs always have you put ticks on things you want literally on the right? It doesn't seem we'd want to bear the consequences of that on HELP...
>> help append
** Script Error: append is missing its series argument
>> help 'append
; this would work...
Just have to keep everything all lined up.