at what point would there ever be 100% agreement on a change? how would you ever be able to measure that? you're trying to confuse things with loaded and political terms. please try and stick to discussing what nodes are actually doing.
let's take segwit as an example.
by running my legacy node in 2017, i opted into to the consensus---i agreed to the current set of consensus rules. when segwit happened, my legacy node retained consensus with all segwit nodes. there was no chain split. therefore, segwit never violated the consensus that i agreed to. that consensus still exists today and i am still opted into it.
with a hard fork, that consensus would be broken by definition. hard forked nodes would be ignored by my legacy node because the two disagree about what the consensus rules are.
as for the whole 'backward compatibility' where older nodes get a stripped out data thats not fit for the full relay layer, and thus forms an underclass of downstream/filtered nodes. yes thats a soft fork as no one is dictatorially thrown off the network. but activating a new ruleset by excluding a certain class from a vote before the ruleset is even activated is not consensus. its a controversial softfork
your position on "downstream/filtered nodes" obviously disagrees with the design as satoshi wrote it:
The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates. The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.
The script is actually a predicate. It's just an equation that evaluates to true or false. Predicate is a long and unfamiliar word so I called it script.
The receiver of a payment does a template match on the script. Currently, receivers only accept two templates: direct payment and bitcoin address. Future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them. All versions of nodes in the network can verify and process any new transactions into blocks, even though they may not know how to read them.
1. yes never 100%. but i was addressing your comment about 100%.. just to correct you that if in YOUR scenario of 100% that there would be no fork. but instead just an united upgrade.
i then went on, passed your limited scope.. and i digressed to show the other parameters of majority(under 100%) and then controversial(less than majority).. it was not me that was highlighting just a 100% agreement. that was you.. like i said i went and explained the multiple levels of what happens when less and less agree and i also described how things play are when nodes are thrown out before consensus(to fake a vote)
...
but in short segwit only got 35% in spring 2017 and so instead of going back to the drawing board with a new option of a varient feature. they doubled down and really pushed for their segwit1x controversially
2. what you dont realise is that downstream/filtered nodes are not just skipping transaction full verification and just saying they pass a minimal test.. these nodes are actually being handed stripped data. which if they were part of the relay layer, the main relay layer nodes would reject the blocks. so its not true compatibility. its just fake compatibility t keep an underclass online but without voting rights (you might want to look into it.. ) the block data 'compatible' nodes get is not the same data full nodes get.
presuming 'compatible nodes' are true full relay nodes and have same vote rights is a flaw in your understanding of the relay network.
3. also before the segwit new ruleset even activated there was a controversial biased fork. some devs called it a bilateral split, amungst many names, but the devs do not deny that a controversial non consensus hardfork occured to push opposition off the network to then get a faked approval vote to get segwit1x activated.
there was no "honest consensus" / "honest node" event around how segwit1x got activated.
some people really need to do some research.. or atleast before trying to deny events happen. atleast speak to devs and realise devs do not need to be defended by lying and saying events didnt happen if said devs are happy to admit their own actions/involvement.
i see no reason for you to pretend things didnt happen. as it defends no one. and also blockdata which is immutible can prove you wrong, let alone quotes from devs themselves. so i wonder what are your motives for continuing the echo chamber of mythical nonsense that a certain group of of people want to continue pushing...
... as the only motive for such i can see is that certain echo chamber group. do NOT care for bitcoin. but only care for keeping bitcoin stifled to then promote another network(LN) where the echo chamber can only hope to become factory/watchtower nodes to be greedy income earnrs.. which if you play out scenario's of LN the echo chamber would soon learn they they wont get to be the hubs of get rich quick. as it will end up being the custodial services of the DCG portfolio that will be the big income earners.. all at the expense of making peer-to-peer self control a thing of the past, while the aim is to push the community into counterparty controlled, banking system which is not community/blockchain confirmed/validated. but instead co-custodian managed and manipulatable. thus killing off the whole point of bitcoin by making bitcoin too expensive and also too small utility to be useful