Ren-C has tried out a lot of new ideas.
Among the ideas that have been kept, most have added some level of complexity. A notable exception would be the 0-or-1 refinement parameter change. That was a welcome simplification--and I am rather confident that nothing of value was lost in the process.
Yet trying to write a usermode pointfree specialization draws out the inconvenient truth: Ren-C's tech could have easily nailed a complete version of what it would take to do historical Rebol's parameter conventions--IF IT HAD NOT RAISED THE BAR.
Rephrasing that: if we were willing to turn back the clock to where there were only four parameter types ("normal", "soft quoted", "hard quoted", "refinement"), then the code I posted for POINTFREE would pretty much work as written...with a little more work for enfix.
All the things that throw wrenches into it are Ren-C-isms:
- Skippable Parameters
- Modal Parameters
- Endable Parameters (this one's not totally new, as HELP vs. HELP TOPIC relied on a similar quirk, but Ren-C generalized it)
Is the Answer to Cut Features?
I don't think so. These features are important.
I think that the evaluator just has to become more modular or hookable. This question of having a parameter to fill, and asking it to be filled from the callsite, just has to be formed as a native in its own right.
So basically: we need a form of EVALUATE that lets you pass in a function which can peek at the input feed and make a decision to pre-process that input. This is somewhat the same needs as the debugger.
MAKE ACTION! from a FRAME! is still quite a good feature. But when your goal is to simulate the evaluator on a stream of input, you need more tools...unless you either burden the person doing the simulation (who will make mistakes) or lose expressivity in the evaluator (which undermines all the interesting work).
The fact that such a simulation is non-trivial isn't a fatal flaw...it's part of what brings the necessary expressivity to make things fun and notable.