Maybe, BUT this is just for the context-sensitive combinators. I believe that this can be made to work without any changes to the “normal” combinator. It makes sense to me that stateful parsing will be less efficient than the highlght optimized things that NimbleParsec does now. That’s the cost of having a more powerful parser.
As long as this doesn’t make the rest of NimbleParsec less efficient, I think it would make sense to include it. But my bet is that you wouldn’t need to. I think I can add a new combinator to NimbleParsec which will allow users to implement context-sensitive parsers without any changes to NimbleParsec.
Also, don’t think of “interpreting the parser” as something very slow and inefficient. You don’t need to interpret the parsing tree at runtime (I hope…). As @OvermindDL1 said, it might just cost the same as a function call, which is perfectly acceptable.
