What were the features they submitted? Stuff that's mentioned on the github page or something else?
https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM%...
Your response is to tell the Internet that Vim is wrong for not accepting broken patches?
It came down to a fundamental design decision—and after months of hard work, they got a non-answer.
"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.
I think the bigger problem was just that nobody could agree on the cancel/freezing timer issue.
To me that's a design decision a maintainer has to make, not someone submitting a patch.
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.