Stability and backwards compatibility were built into neovim from day one. I used it from the 0.1 days, never had a crash, and all my vim plugins just worked. They put incredible effort into not breaking compatibility with existing vimscript, even as they constructed a new, modern build pipeline and development model, and refactored 30% of the code out. It wasn't until they added features of their own that full compatibility was lost because Bram wasn't interested in porting their work back to vim.
This really wasn't "move fast and break things". It was "vim development is stagnant, our only choice is a fork." And now Vim and Neovim are now vastly better pieces of software than Vim 7 was. Forking Vim did wonders for Vim itself.
This seems more like an inexperienced developer getting frustrated with the process. I absolutely would expect that new contributors will have to go through multiple revisions before they can get anything merged.
When I started working as a junior dev my first merge request had more comments from seniors requesting changes than lines of code. It can be absolutely brutal but that something everyone needs to go through.
If he had tried for years he might have had a point but just because it took months does not mean Bram was not interested in the patch at all. Otherwise he wouldn't have suggested any fixes.
Seriously, you don’t have to love Neovim, but credit where it’s due.
Yeah, I took a bit longer for async to land in VIM proper but how is that a problem? Isn't is good that Bram put his foot down and insisted to do it right-way instead of the fast way?
There is already enough "move fast and break things" software out there. I am happy for neovim and some innovations are interesting but for me the disadvantages of less stability are not worth it. I don't really see a need to increase the "bus factor". VIM is not a business, it can afford to move slowly but purposefully.