Obviously the only possible solution is to attempt another fork/reimplementation of emacs. This one will definitely win and not be totally irrelevant like all the others.
The impact of these forks is that the community around the main project is slowly eroded. But it doesn't really matter whether the fork brings the main project to the negotiation table. The author of TA is able and is committed to carry and maintain that patch in his local repository until the end of time. What is missing to complete such a fork is publishing that local repository.
I have a hard time putting faith in that “balkanization theory” from the '90s anymore. A fork gains traction if and only if it manages to get ahead of the mainline feature-wise, and stay there, by a sufficiently wide margin for customers to overcome their inertia. We'll see whether this ~eshel person manages to pull that off, or not (my money is on “not”.)
Forking Emacs on such grounds is a symptom of ego malfunction. The proper step (after diplomacy has failed, which it hasn't yet in this instance) is to author an alternate implementation of the feature in Emacs Lisp and publish it.
The easiest way to produce a monkey patch for Emacs which reverts some behavior would be to maintain your own private fork of the repo, where you do a proper job of rebasing, resolving conflicts and validating. Then from that you take the necessary files (all the files that are different from upstream) and produce the hot-load that can be distributed to people. But, totally not a fork, man!
