Historically, there were no infix dispatches via path. In R3-Alpha:
>> obj: make object! [plus: :+]
>> type? :obj/plus
== op!
>> 1 obj/plus 2
** Script error: op! type is not allowed here
In Red, it does... uh, something? But not what you'd want:
>> obj: make object! [plus: :+]
>> type? :obj/plus
== op!
>> 1 obj/plus 2
== 2
There are mechanical reasons why it is difficult to make work how the code is written in both of them. Let's ignore those; particularly because Ren-C is under much more control and should be able to finesse the mechanics for any design--assuming they're not paradoxical. So the bigger issue is philosophically why it seems it can't work...which is GROUP!s in paths.
For a path with GROUP!s in it, in order to find what that path might resolve to requires evaluation. Evaluation runs arbitrary code. And enfixedness relies on lookahead; to be able to know what is on your right before making a decision about how execution will proceed. If you have to perform an arbitrary evaluation to know whether you can proceed, you might wind up running code you don't need to.
Just a simple example to make the point:
a: make object! [b: 20]
do/next [print 10 a/(print "this shouldn't print" | 'b) 30]
But if a/b were enfixed addition, "you'd expect" to get the printout from the GROUP! and then ultimately a result of 40. So until someone figures out a solution to that whole halting problem thing, the lack of a "psychic" evaluator means we're screwed. So it seems that paths with GROUP!s in them can't be considered enfix candidates.
Yet the simplest compromise may be right in front of us, which is to have lookahead try to evaluate a path, but "give up" if it sees a GROUP!. If it doesn't give up, and terminates by locating an enfixed key (remember it's the binding that's enfixed, not the FUNCTION! value)...then run the enfix semantics. If it does give up, and that that same PATH! with a GROUP! in it is evaluated later in its proper order to find an enfixed key, give an error.
This will involve some extra processing on paths, but I think it can be cheap. The way the caching for word lookup is written for lookahead should be able to be reused more-or-less for path processing, to avoid two path lookups in the common case.
So as long as we think people would rather have some enfix path lookup instead of none, it's a good tradeoff. Agreed?