If 51% of the miners decide to fork, I think I will follow the majority and support the fork to get back the money from the attacker.
Satoshi had a term for that, he called it attacking the network:
As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network ... - Satoshi Nakamoto (bitcoin.pdf)
So, no, there has been no "hack" or "attack" so far, but Vitalik, Tual, and their cronies are working on one.
Soft forks are 51% attacks. At best, when done for relatively-benign upgrade purposes, they demonstrate a vulnerability of the network and should still raise some level of concern that the developers and miners are able to conspire to pull off a 51% attack. When done transfer control over coins, that is outright theft.
Smooth if forks are authorized by a protocol that was designed in the coin from the start, i.e.
an ability to vote on changes by stake holders for a PoS coin (e.g. DASH), then that appears to not be a 51% attack. But otherwise I agree with you, and when you have the same group of devs from the ICO able to control the politik then they are essentially running the enterprise.
There is a grey area where someone from the outside creates a fork and the users and miners spontaneously decide to switch over to it. This can be argued to be a feature of decentralization and open source, and necessary to correct deficiencies. Yet it is still a 51% attack. If done with proof-of-burn, then it is not a 51% attack.
But your analysis of the issues here seems to be oversimplified because the law interacts with all this to create more complex scenarios. Please read this:
https://bitcointalk.org/index.php?topic=1517223.msg15271289#msg15271289I'm not really sure that "authorized voting forks" are even compatible with Satoshi's original design at all.
He wrote that the nature of the system required that its core properties be set in stone forever. Probably the ideas of governance and voting were considered by Satoshi(s) during the years of development, as they are pretty obvious ones to consider.
A reasonable conclusion (and one I have reached somewhat independently) is that "set in stone" is required because there is no good way to differentiate between good changes and bad changes. Allow changes (e.g. by "voting") and the structure collapses in on itself.
Limited time to read or comment more, will do so later.