The approach that you suggest (including the compiler with the binary) is exactly the "bundlemonkey" approach that jonadab ruled out. And my claim is that if you rule that out, then you run into problems with eval.

Actually, tilly, what adrianh is suggesting is not the bundlemonkey approach. There's an important middle ground: include optimized native code, not bytecode, and also include a compiler that generates optimized native code on the fly when necessary. This is significantly different from producing bytecode and a bound interpreter.

On further reflection, including the compiler (which converts source to bytecode or native code) or not and having code as bytecode + interpreter (bundlemonkey) or as native code are really orthogonal choices. Many commercial lisp variants produce output that has the compiler but also uses (mostly) native code, whereas Visual Basic programs take the opposite approach: classic bundlemonkey but without runtime access to the compiler.