My questions are aimed at the people against this hardfork to understand what degree of decentralization and security which would make them comfortable as their primary concern deals with the risk of centralization and decrease of nodes.
Thank you for your valuable attention and contribution to this!
Over its history, Bitcoin users per nodes has declined from >1:1 to now something like <1:700 (from the calcs upthread).
Looking at it another way... # of nodes contributes an element of security (resilience) where N is the minimum to run, N+1 is with one 'hot failover' system for backup, we have something like N+7000... which so far has been more than enough.
The question posed here boils down to: 'how much security is needed?'. An honest answer to this is always going to be: 'I don't know until we don't have enough.' So far, Bitcoin has had enough. So far Bitcoin has also had enough space in the blocks for meaningful transactions. These two virtues are come into conflict with this proposed fork.
So where the (A) number of meaningful transactions, is empirically observable; and (B) the amount of security needed, is only knowable after it has failed.
From this, a simplified risk analysis.
As (A) increases, Bitcoin's value increases. As (B) increases, Bitcoin's cost increases.
Increasing either (A) or (B) also increases risk to Bitcoin: In brief, The more value Bitcoin has, the greater the incentive to subvert it. The greater cost to Bitcoin, the easier it is to subvert.
The optimal management of this A:B ratio for greatest Bitcoin value and security would be a block size that permits all meaningful transactions to be swiftly included in blocks, but not so large that it permits excessive spurious transactions for which the cost is borne by all... So a hard fork to accomplish this is desirable, just not "at any cost".
This brought me to needing a proposal for such a fork that is "Not both inaccurate and indefinite".