The main reason not to reach for metaprogramming in this case is that it all works on expressions, the state of the code between the unparsed text and the evaluated working code. Nothing can change the method body once evaluated, you can only replace the method entirely (which is not worth doing all the time); once compiled, variables don’t typically exist anymore; a method call-time value like output is far too late. Many examples of mapping data structures so far, but the most primitive selective structure across languages in history would just be a conditional branch, far predating any metaprogramming features:
if output == "a" return a
elseif output == "b" return b
end
Still, I concur it’s not a great design to toss out outputs in the same method that computes them. Let the user get everything from one method and filter those separately, it accomplishes the same thing without forcing them to learn a method-specific API to do everything in one step. You definitely do not want to vary the returned expressions among methods calling each other, simplify to consistent outcomes instead of maintaining a nightmare.