Are you familiar with Vim's code? Just look at all the OS-specific files in the source tree[1]. Not only that, there are ifdefs-galore in the shared code. RealWaitForChar is over 400 lines and contains 41 ifdefs.[2] Many are for long-dead features or platforms. That function just waits for user input, but it has to be ridiculously complicated to account for platforms without basic functions like select(). The infamous eval.c starts off with ifdefs for Amiga, VMS, and Mac OS Classic.[3] Neovim has ripped out tons of this stuff, and it's drastically reduced line count.

1. https://github.com/b4winckler/macvim/tree/master/src

2. https://github.com/b4winckler/macvim/blob/master/src/os_unix...

3. https://github.com/b4winckler/macvim/blob/master/src/eval.c

I think the parent can be read as an honest request for more details. It doesn't need to be met with snark.

(Don't take this too harshly - the content in your post is good.)

How does this stuff get in the way of the features that NeoVim intends to add? -- features they list such as "job control", a msgpack remote API, or a new plugin architecture. (I don't really expect you to be capable of answering this question unless you're familiar enough with the code to give an operational description of how these ifdefs get in the way.)

You don't have to be familiar with Vim's code to know that having support for obsolete OSes makes the code substantially more complicated.

It depends on how much the compatibility issues have been factored out into external libraries. In the case of vim, I think the answer is "substantially not".