Any worry about latency with this new plugin architecture? I'm not quite sure how the current plugins communicate with the main process, but I am sure that one of the things I would most like to see in a re-write of vim is a more responsive interface, even if I have a handful of plugins running.
If anything, the NeoVim will be much more responsive. Vim's current plugin architecture is simple: when plugin code is running, the UI is blocked. If your plugin has an infinite loop, Vim hangs forever. If your plugin does network I/O, Vim hangs until the socket read/write is finished. The only work-around is to use non-blocking sockets and abuse CursorHold/CursorHoldI autocommands and updatetime. That trick breaks the leaderkey, which is a show-stopper for many users. There are similar problems with syntax highlighting. Vim has its own (extremely inefficient) regex engine that blocks the UI when matching.
There's plenty of room for improvement. For example: if you run the same regex many times in a row, Vim rebuilds the DFA on each run. A cache of recently-used DFAs would avoid tons of wasted computation. Also, Vim doesn't free many regex-related data structures until you close the buffer they were invoked on. I had to work-around that bug when writing a plugin, since it caused Vim to use gigabytes of memory.
The best solution would probably be to switch to PCRE. Some Vim-specific stuff[1] would have to be special-cased, but Vim could get an order of magnitude speedup (and fix quite a few bugs) by using a modern, optimized, well-tested regex library.
