Multicore is not common at all in embedded, so there is no point in supporting that in this type of project. And even if you are in "fat" embedded (Raspi etc.),

Multicore is not common at all in embedded, so there is no point in supporting that in this type of project. And even if you are in "fat" embedded (Raspi etc.), you might want to use just only one core anyway so that your system can do other things efficiently (or use less power). For interpreters like this, what you should be looking for is not direct support for this or that, but how easy it is to write bindings for that interpreter. In my opinion, what Lua offers is the yardstick there. Oh, and don't stop at FFI support. FFI is IMO generally the worst option as it introduces a lot of overhead both at programming time and/or at runtime. I have a personal interpreter - it's not Lisp-based but Forth-based (rule 48: everytime Lisp is mentioned on a forum, someone mentions Forth and vice-versa) - that is very easy to extend with libraries. I actually use it sometimes to experiment with libs. I have dabbled with most of the examples you give (and more). For tiny interactive interpreters aimed at embedded (otherwise for most people there's no point in the "smallest possible thing that can..."), what you should be looking for is not spoon-fed features, but how much control you have over the runtime. Well, that's my way of thinking for non-embedded stuff too.