Terminology issues consist of inter-language conflicts among definitions of technical terms like "list", "scope", "variable" or "macro" and such.
The proper noun that Lutz Mueller chooses to call his project is not a definition of a technical term.
To me, NewLisp is uninteresting. I already know how to avoid sharing issues in memory management in C programs by mallocing a copy of everything and duplicating it; that bores me. Lots of programs in POSIX environments do that with strings: strdup everything you receive, and cheerfully free it knowing that nobody else has that pointer. NewLisp is just doing "strdup for lists". It might as well work using strings, just like the "Lisp in sed" implementation: https://github.com/shinh/sedlisp . Why use objects, when pictures of objects provide a reasonable facsimile? I know how fexprs work, and they bore me also. Once you allow them, you can kiss goodbye the future prospect of having a compiler. As an implementor, if I want to introduce a new special operator in an interpreter (a decision not to take lightly), I can write it in the hosting language (such as C), and not as a fexpr. By writing such an operator, I get essentially the same development experience as if I wrote a fexpr, without inflicting harm on the language. If interpretation is a wart, then interpreted code being dispatched to interpret code is a tuft of hair growing out of wart.