People who basically want him to never change (and that is fine) can be happy with mainline. There are others who would like to see some significant updates, particularly allowing better threading support.
Sounds to me like you need to go farther. "We should improve what we have" totally fails as a criticism when written by the same guy who won't let the product in question be improved.
If there's good reasons not to admit patches, fine, let's hear them, but don't give me this glib "we should improve what we have" crap. I can hardly believe that's basically his only answer.
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.