> Please, not every shitty Lisp interpreter which can print to the screen and take user input is an operating system. Not every Lisp program which can send mail is an operating system.
I agree with that point.
Calling Emacs an OS is dubious, it certainly isn't a general purpose OS, and won't run on real hardware. But, let me make the case that Emacs is an OS.
Emacs has two parts, the C part, and the Emacs Lisp part.
The C part isn't just a Lisp interpreter, it is a Lisp Machine emulator. It doesn't particularly resemble any of the real Lisp machines. The TCP, Keyboard/Mouse, display support, and filesystem are done at the hardware level (the operations to work with these things are among the primitive operations provided by the hardware). Of these, the display being handled by the hardware isn't particularly uncommon, historically; the filesystem is a little stranger.
The Lisp part of Emacs is the operating system that runs on that emulated hardware. It's not a particularly powerful OS, it not a multi-tasking system. It has many packages available for it (though not until recently was there a official package manager). It has reasonably powerful IPC mechanisms. It has shells, mail clients (MUAs and MSAs), web browsers, web servers and more, all written entirely in Emacs Lisp.
My might say "but a lot of that is being done by the host operating system!" Sure, some of it is, but all of it is sufficiently low level. If you wanted to share the filesystem with another OS running in a VM, you might do it by sharing it as a network filesystem; this is necessary when the VM OS is not designed around running in a VM. However, because Emacs OS will always be running in the Emacs VM, we can optimize it by having the Emacs VM include processor features mapping the native OS, and have the Emacs OS be aware of them. It would be slower and more code to do that all over the network.