In your example [ of increasing the block reward ] users who chose not to switch over to the invalid alt software would definitely not accept those coins. You just admitted so yourself.
Any change to the protocol, soft or hard or otherwise, will require users to upgrade their wallet software eventually. The question is WHEN they would have to upgrade, and what will happen if they don't.
With a hard fork change, users must upgrade
before the change is activated by a majority of the miners. Users who fail to do that may find that their wallet software stops working (if almost all miners convert), or that it becomes much more sluggish, and will be using a forked altcoin (if a significant minority of miners refuses to convert).
With a soft fork, the old client software will work to some extent after the change is activated, but will not be totally functional. The consequences of continuing to run old software will depend on the change.
For soft-fork changes that do not introduce "extension records", the old client software gets all the information, but fails to chec (and notice) that there are new restrictions about transactions and blocks.
For one thing, he may therefore accept blocks that new clients consider invalid; but that is not much of a problem, unless those blocks are backed by the majority of the hashpower -- which is to say, the miners reversed the change.
A more serious problem is that the old clients may issue invalid transactions, and will not understand why those transactions are never confirmed, or even propagated. For example, a wallet that did not incorporate the BIP66 soft fork may issue transactions with invalid signature variants. (IIRC, Master Spoiler @AlisterMaclin exploited this fact in one of his pranks, a couple of months ago.)
Another example is the idea of introducing demurrage, or negative interest: a rule by which old bitcoins lose their value at a fixed rate -- say, 5% per year, compounded daily. With that proposal, if you received 100 BTC two years ago, you can only send a little more than 90 BTC to someone else: the other 10 BTC will have to go to the miners, somehow.
Demurrage is trivial to implement as a soft fork: the majority mining cartel needs only decide that a transaction is invalid if the transaction fee does not include the negative interest amount. Miners individually can already do that, but those transactions can be picked up by more generous miners. Making that rule part of the protocol means forcing all miners to respect it: because the cartel will orphan any block by other miners that violates the demurrage rule.
After this soft fork, old client software will still seem to work, and see the same blockchain as everybody else. Users would be able to spend any small amounts of bitcoin that they received recently, since the standard tx fee would cover the demurrage tax. But transactions spending larger and/or older inputs would be mysteriously rejected. Users would have to learn about the new rule, and either add the demurrage tax by hand, or get a new wallet that implements it automatically.
(5% per year may be enough to convince most holders, traders, and bitcoin services to move to an altcoin, forked from bitcoin or not. But it would not bother people who use bitcoin as a currency. A more modest tax, say 1% per year, may be acceptable even to holders, since they implicitly believe that the price will rise a lot more than that. Anyway, the point here is not whether a demurrage tax could pass, but to explain that, even in a soft fork, the old client software will not FULLY work, and clients will be forced to upgrade eventually.)
In the case of soft-fork changes that create "extension records", like SegWit and my "extra block reward" scenario, users and relay nodes who are running the old software would not even receive that extra information. In the case of SegWit, for example, old users and nodes would be unable to check whether confirmed transactions were properly signed by the coin owners. Those old player will not see the signatures, and will not even know that they are required. I cannot see any serious harm that can result from that; but I could not see the Fork of July coming either. Who knows what Maclin will be able to do after SegWit is deployed for real...
Finally, in my "extra block reward" scenario, the old clients would be unable to see the new block reward coins created in the extension records, or any transaction outputs that get tainted by them. But both old and new clients would continue to work together, as long as they exchanged only old untainted coins. It may take months for the new reward coins to spread and contaminate a significant fraction of the coins in circulation. Exchanges that adopt the change would want to keep separate hot and cold wallets for old clean coins and for new or tainted ones, to keep old clients happy for as long as possible. But, perhaps many months after the switch, the old clients would be forced to upgrade -- because someone sent them tainted coins that cannot be ignored or returned, or because their exchange ran out of old clean coins, so clients who withdraw will receive only tainted coins.
You could call those extra reward coins "just an altcoin that is merged mined with bitcoin", but it is more than that. For the users of the new software, there will be no difference between that two coins. A new client can send coins that he received from anyone to any address, without knowing (or having to know) whether those coins are clean or tainted.
Of Course some idiots will fall for [ a different implementation that creates extra reward coins ] , but most will be alarmed and do a speck of research before accepting the fraudulent software.
Maybe, if the modified wallet software comes from a new source. But if its comes from Core, or from an established wallet software provider -- probably no one will check (or care). How many have checked the previous releases that introduced soft forks?
A year or two ago, Blockchain.Info (BCI) deployed a new version of their wallet software with a totally broken random number generator, that made all new private keys trivial to guess. The bug was discovered a few hours later; but not by one of their million (?) users, instead by a white-hat hacker who was monitoring the blockchain for certain key-exposing signatures. Yet BCI's wallet is deployed as source (javascript) not binaries.
How many do you think will bother? My guess is fewer than 5000 bitcoiners...
21 million is so intrinsic to the identity and contract of bitcoin most would move over, but for the sake of argument lets assume only 100 people move over... Do you really think we care? You are making an assumption that we are only greedy speculative traders who have no principles. I will never accept or use a bitcoin alt that changed the inflation rate.
Why would anyone care about the inflation rate, if one is not a greedy speculative trader/holder?
The people who use bitcoin as currency certainly could not care less about its inflation rate, or even it price. They would use bolivares, if bolivares could be used the same way as bitcoins...
And the 21 million is not "intrinsic", it is an arbitrary number that was put in partly for economic naivete, partly for rather quaint technical reasons.
And there is no "contract", just as the rules of chess are not in any contract. The protocol is out there; anyone can issue transactions and mine. And everyone is free to make up his own rules, and take whatever that will bring.
Poll
