That's how the softfork worked before it got scrapped. A hardfork literally splits the network in in two, it's basically like creating a new coin shares the previous history.
How does the fact that it was a hardfork invalidate either of the statements above? It's known ahead of time, and if not enough people adopt it then it doesn't get activated at all.
The way it invalidates the above statement is that there's no code that decides whether the fork happens beside what flags the nodes are launched with.
At the specific block number the nodes that accept the fork will only validate the hardfork blocks as correct while the nodes that don't support the fork will reject these blocks. Thus two chains will co-exist for an unknown amount of time, not just one or the other.
To some extend what you're saying is true though as it's very unlikely that both chains will remain active/retain it's value and therefore miners on the losing chain will likely move to the winning chain very fast to avoid losses incurred from the cost of power.
>there's no code that decides whether the fork happens beside what flags the nodes are launched with
That's not what you said above. You claimed that the mere fact that it's a hardfork means that you cannot implement anything to only activate if there's a majority. But it's extremely simple to do so. Just check whether a supermajority or a plain majority of recent blocks have signalled support for the hard fork, and only produce hardfork blocks if they have.
>The community tool carbonvote will be used to set the default fork option for Geth. At block number 1894000 the votes will be tallied, and the outcome will determine whether the default is set to fork or not to fork. Then merging the DAO fork PRs will proceed, followed shortly by a release for both Geth and Mist.
So they're only going to merge the hardfork code if they already have the votes.
i did not mean to imply that a hardfork can't be implemented in that fashion, I should indeed have written "the hardfork" instead of "a hardfork" as that's the way this specific hardfork has been implemented, I appologies English is not my native language.
My understanding of that blog post is only what the default value of supporting or not supporting is meaning the hardfork code will be merged in either case and that it's only whether it's active by default that's changed depending on the vote.
Not that it really matters anymore as block number 1894000 has already passed and the code merged with hardfork support enabled by default.
This is also an existing problem in every cryptocurrency. Just because bitcoin hasn't done any controversial forks yet doesn't mean it will never happen.