Related: ENBIN and DEBIN:
BINARY! Dialected Encoding/Decoding instead of TO conversions?
They make you be explicit about the endianness, and I thought using +/- to indicate signedness was cute.
If I get the gist of your rethink (?) it seems a bit like you are thinking that reinventing basic primitives in each dialect is a losing battle... because you'll miss some. So you want to inherit all the control flow types of operations by default vs. reinventing that each dialect.
For other-language inspiration on this front: Haskell doesn't quite do that, but offers a certain reusable form of operations that can be used in their "dialects" (monads, which you might think of as being dialect-like, in some school of thought).
Their REPEAT that can be used in parser combinators is the monadic operator replicateM:
https://hackage.haskell.org/package/base-4.14.0.0/docs/Control-Monad.html#v:replicateM
Which you might think of it kind of like there are some forms of REPEAT that know they have some state they need to tunnel through to their bodies that come from the "dialecting context" and a more fundamental form that lacks that context.
Fairly sure this is bait for a lot of where Ren-C has gone with uparse/streaming/ports etc.
The merging of UPARSE with evaluator services is definitely a thing, because they have so much in common...like "current expression" for telling you where an error is, feeding along the code.
So I see the likelihood that UPARSE is one of those "parameterized evaluators" I was speaking of.
But I also was thinking of implicitly allowing any function with a certain signature to act as a combinator... if it takes in input and has a named output saying how much it consumed, then you'd have instant combinator with just minus one parameter (input implicit).
This made me think maybe ENBIN and DEBIN could be those kinds of functions.