The number of lines of Elisp my Emacs uses (counting plugins, but also built-ins) is actually more than twice the number of lines of C.
It's not that "Emacs contains an interpreter", rather it's "Emacs has all these features written in Elisp [...a looong list here...] Oh, and it also has an interpreter to execute it all".
Some features like memory management (garbage collection) are layered on top of the OS.
The UI is not 'native' - it's based on a portable substrate written in C/Lisp, which works both on WIMP and terminal systems.
The user interaction is not native (commands, buffers, undo, preference dialogs, window/frames, ...).
etc.etc.
Let's just agree to disagree. We are talking past each other at this point. Best regards!
Because compiling code to the native instruction set shouldn't affect the semantics: so why should that be the only yard-stick for "native", right?
What is semantically relevant is: how much of the platform is exposed to the programs directly, versus through abstractions.
Suppose a language like Emacs Lisp or Java or whatever has only thin wrappers around POSIX through which applications interact with the platform. Then those programs are quasi-native POSIX programs, really. They are doing things like fork, waitpid, dup2 and whatever almost directly. And suppose that in the Windows version of that language, programs use functions that mimic CreateProcess or WaitForSingleObject. Then, regardless of the language being interpreted, it's really a native programming language.
If forced, I would say that Emacs-the-platform is native, and Emacs the system of Editor MACroS is not, since the macros run on the Emacs platform. But it seems kind of pedantic.