It's obvious you'll never come around as you are just here to promote XT. Nevertheless, I'll address this tired underlying assumptions that "people would still need to choose to download and install the new implementation" somehow magically protects Bitcoin for generations to come:
False assumption #1: Everyone who downloads the program completely understands the code.
The vast majority of people do not understand the code, and most are not programmers. Most of us, even those of us who program and can read code, downloaded and ran Core without having any idea about the details of what it does. (e.g., does it log IP addresses?) The reason I take time to post on this forum about the risks of XT is so people can make a more informed decision, and if they decide to install XT, will at least hopefully be wise enough to question each upgrade. Ditto for Core upgrades. Hopefully, discussion like this help broaden awareness of the risks of new code.
False assumption #2: Those who do have a better understanding of the features of the program they download are guaranteed to understand the implications of those features.
The reality is that unless they do understand the implications, they are likely to take the purpose of the code at face value for what its author claims it will do. Undoubtedly, there are some who installed XT who feel protected from DoS attacks because of the patch Mike put in it. Unfortunately, had they read the thread with the Core devs when they rejected it, they would of known that (a) the only claim of a Tor attack was on Gavin's node with no evidence that any other node ever had an attack via Tor, (b) neither Gavin nor Mike provided logs or other evidence of the attack when the Core devs requested it, (c) the Core devs listed many reasons why most DDoS attacks are likely to come from non-Tor sources, (d) even Mike acknowledged that innocent Tor users would be harmed by it and (e) when the attack came from likely non-Tor sources, only Tor would effectively be blocked, not the DoS sources it was supposedly intended to counter. Additionally, (f) this is intended to evolve, and could evolve with enough critical mass combined with XT whitelisting to make it very difficult to unseat XT as the primary code for Bitcoin nodes.
Does the XT website discuss any of this? No. Not only does it ignore all concerns raised by the Core team, Mike has even publicly made statements about the process in which this patch was rejected by Core that very deceptively try to make the Core team look like the bad guys but conveniently leave out the truth of why Core rejected it. Fortunately, the dialog between the Core devs and Mike on his pull request is very public for those interested in reading it.
https://github.com/bitcoin/bitcoin/pull/6364I am sorry to oversimplify your argument but you are essentially saying that people can not be trusted to make the best decision in terms of what implementation to run. This is however where I believe the fundamental choice and source of the voluntarism of Bitcoin should and does lie. Not governance structures build on top of an implementation or on top of the Bitcoin blockchain, since then we would run into some of the same old problems that large organizations and states run into. The consensus mechanism for resolving such disagreements already exists and it depends on what code people choose to run and where the miners direct their hashing power. Maybe you are correct and the economic majority will not make the best decision, however this freedom of choice is so important and fundamental for maintaining the freedom and decentralized nature of Bitcoin that this would still be the best path to take. There is an irony in accusing XT of dictatorship while simultaneously saying that people should not be trusted with the freedom of choice.