As it happens, Ren-C started out with an option to not build in an interpreter.
But that wound up requiring functionality that duplicated PICK. e.g. an API that did what pick did...just bypassing the evaluator. Or what APPEND did, just bypassing the evaluator.
I pretty quickly panned that as a direction that had much likelihood of success (although it is what libRed did a year or two later). So the API was restructured around variadic calls into the evaluator:
Limiting API Entry Points in Favor of Exchanging Strings
It's been incredibly versatile in the tasks it has been used to attack. Stacklessness makes it moreso...it means you can have a thread of execution on a host that wants to do an enumeration, and it can be calling a generator that is based on Ren-C code which yields to the host language's loop control.
I guess it seems like you're saying Boron has also not taken so much a libRed angle, just paring down how many primitives those are (?). e.g. your API currency is still cells, not series pointers (Nope, there's UBuffer which is basically a REBSER, see post lower down)...but you don't have a lot of entry points for cell operations:
UStatus boron_load( UThread*, const char* file, UCell* res );
const UCell*
boron_eval1(UThread*, const UCell* it, const UCell* end, UCell* res);
UStatus boron_doBlock( UThread* ut, const UCell* blkC, UCell* res );
UCell* boron_reduceBlock( UThread* ut, const UCell* blkC, UCell* res );
UCell* boron_evalUtf8( UThread*, const char* script, int len );
Ren-C might be said to be "more extreme" in the sense that there's no separate entry point for REDUCE (or DO), you call it like anything else through evaluation. (though it has a lot more entry points for extraction, e.g. unboxing of integers is folded in with a variadic evaluation, so you can do your calculation and the extraction all without giving an API handle to the client)
All right, I guess I now know the scope and limits of Boron. Which is what I asked, so thanks.