Bram's last post was 10/21/13, and a month later Bjorn confirmed in his fork that he could reliably freeze VIM and had segfaults that he had yet to fix. The final word seemed to be:
"There are enough vim users out there (myself among them) to warrant supporting a fork for as long as we're around. We'll try to keep it up to date with the latest changes."
I don't think anyone should expect Bram to chase them down for updates to the patch. Reading through the discussion, it seems clear to me that while good-natured, the feature was not ready to be merged into VIM.
We actually continued to work on the fork until it was clear Bram wouldn't be responsive to any more changes. Once it became clear he wouldn't accept the patch we stopped wasting more time as we are trying to create a viable business. We weren't going to sink our startup for the sake of vim, as much as I love the editor. We spent a long time, it was a frustrating experience, so yes we tell the internet when it comes up. Any of the freezes we found we would have loved to patch back into vim had this gone differently, and it would have been a lot of work.
My only takeaway from the thread was that you approached the process of patch review begrudgingly, and seemed to assume that everyone should understand/appreciate your node-derived vocabulary and design.
Each iteration of the patch was provided with a whine about whether it was ready for inclusion yet ... when the reality is, that as the patch author, it's your job to make sure there aren't more bugs and the patch is ready for inclusion.
Every time someone found another issue was a red flag to any sane maintainer that your patch wasn't ready for inclusion. Every time you whined about having to iterate, you made it clear that you couldn't be trusted to have written something stable and maintainable.
If you can't deal with working on mature software, stick to startup code.
It came down to a fundamental design decision—and after months of hard work, they got a non-answer.