In the block size fork, the proposal is to have the miners vote. However, the users of the system (merchants/exchanges/clients) are the ones who have control in the end. They choice made by them is the one that has the support of the economic majority.
One way to measure that choice is to see which fork has the coin with the highest value. If a fork is not very popular, then its coins on that fork will be less valuable.
Assuming that the XT fork activates, then the XT fork will have the support of 75% of the hashing power and the core fork will have at most 25%. If the core fork still has reasonable hashing support, then it would continue, though with around 45 mins block time.
If any of the inputs into a transaction spend a coinbase output from one of the forks (or any of its descendents) that it can only be included on that fork. This allows trading coins between the two forks.
Exchanges could add BTC-XT and BTC-core coins to allow trading between the two forks. This would clearly show which fork had the support of the economic majority. If the loser doesn't go to zero, then at least some people want to keep it going.
This trading cannot happen until the fork itself happens, so can't be used to tell in advance which side has the support of the economic majority.
This could be rectified with a soft fork. It works similar to colored coins. Outputs have information about who can spend them on each fork. Each fork has an id based on the fork deadline.
Fork-id = 0 means the core chain
Fork-id = deadline means fork chain
The deadline is the unix timestamp of when the hard fork is going to happen. Each fork would have to pick their own switch moment, but that isn't that big a restriction. It is not likely we are going to have more "serious" hard fork proposals than one per second.
The soft fork allows the user to specify who owns the output in each of the potential forks.
A user can spend their money to the following output script. This is a template match like P2SH.
<fork_id1> <fork_id2> OP_DROP OP_DROP OP_HASH160 <hash script 1> OP_EQUAL
<fork_id3> OP_DROP OP_HASH160 <hash script 2> OP_EQUAL
This spends the output to
In forks 1 and 2, the owner of script 1 owns the owner. In fork 3, the owner of script 2 owns the output.
To spend an output, you include
<signature for script N> <script N> OP_1
The OP_IF activates and the script is checked like with P2SH.
You can spend multiple rows.
To skip a row, you just include
This causes the OP_IF to skip that row.
In the outputs, the sum of the inputs for a fork id must be greater or equal to the sum of the outputs for that fork id.
All signed inputs can be consolidated as desired (and committed to fees). Unsigned inputs must have outputs equal inputs, since it isn't your money to commit to fees. If two inputs pay to the same script hash, they can be consolidated.
Once the deadline has passed, it is possible to convert encumbered coins back into normal outputs.
In the core chain, once median timestamp is greater than the dead line, once the fork id = 0 row matters and nobody else is allowed to spend the output. On the fork chain, only the output that paid to the deadline is spendable.
This allows users of legacy BTC to convert x BTC into x BTC-Core and x BTC-XT in advance of the fork. These can be traded on exchanges to determine the view of the economic majority.
If most users think large blocks will destroy Bitcoin, they can convert their BTC to BTC-Core. On the other hand, if they feel that a block size increase is necessary, they can convert their BTC to BTC-XT. Both sides would be putting their money where their mouth is.
The most valuable coin isn't necessarily the winner. If both sides maintain some value, then the fork will split the coin. On the other hand, if one coin is trading at a few percent of the price of the other, then the economic majority would have given a clear verdict.