@hostilefork: in the spirit of reduction, here's a slightly perverse experiment.
Take the Glon ABI — the same way I gave it to @rebolek — and implement it on Ren-C. Don't use our implementation as the model; just satisfy the ABI and see whether the existing Glon examples still run unchanged.
Glon is really a macro assembler, increasingly intended as a small, abstracted and provable language for LMs. Ren-C would be the portable machine underneath it, while retaining useful things it already has — TCP, files and the rest of its cross-platform machinery.
You can continue writing Ren-C directly and doing whatever you like inside the trapdoor. The LM doesn't need to go in there. It programs against the much smaller Glon abstraction on top, whose semantics are deliberately constrained and testable.
There is one important requirement, though: Glon needs a frozen Ren-C core underneath it.
That doesn't mean freezing Ren-C. It means defining the minimum Ren-C machine that implements the Glon ABI, freezing that contract, and letting the rest of Ren-C continue to evolve above and around it.
That also removes much of the bus-factor problem. Once the Glon ABI, tests and the Ren-C core beneath it are frozen, nobody needs to know what was in Brian's head when the machine was written. The behaviour is the specification.
And if you do this, you gain Glon's cooperative multitasking rather than having to design a separate multitasking system for Ren-C.
It needn't mean adding another couple of hundred kilobytes either. As the frozen core is identified, it may become apparent that parts of the existing evaluator are no longer required for this machine. The combined system could ultimately become smaller, not larger.
So the experiment isn't "replace Ren-C with Glon".
It's: freeze a small Ren-C machine, put the provable Glon abstraction on top of it, let the LM program Glon, and see how small the machine underneath can become.