From PL_keyword_plugin, an opcode tree must always be generated. Whatever code is generated, even a single no-op, perl should resume parsing the (possibly modified) code remaining in the source stream.

In the example in Keyword::Simple, the provided keyword was consumed by the parser and the keyword handler called. The handler "stuffed" if in front of the current content of the source stream, "generated" a no-op then returned KEYWORD_PLUGIN_STMT, leaving the rest of the statement for perl to finish parsing.

For a keyword in an expression, a similar series of steps should also work.

In the case of XS::APItest::KeywordRPN*, the handler would have had to parse the expression itself, consuming the expression. At that point, the handler could have either generated an op-code tree for the parsed expression, or stuffed the source stream with an equivalent expression that perl could parse and generated a no-op.

In theory, a no-op should no have effect (other than consuming time), even in the middle of an expression. When XS::APItest::KeywordRPN was working, it may be that it was generating an actual op-code tree for the RPN expression. In which case, that could be what's necessary to implement an "expression keyword". If it regenerated the expression for perl to parse, then probably something changed in the Plug-able Keyword API that XS::APItest::KeywordRPN was never updated to comply with.

---

* Other than downloading the source distribution for perl (which I have no inclination to do), I have not found the XS source for XS::APItest::KeywordRPN, so I can only theorize on how it worked.