Is no-one concerned that by attempting to bring a fork into existence, and not calling it CLAM, or Litecoin, or some such, but essentially, Bitcoin, anyone who has been considering buying Bitcoin for its scarcity and fixed monetary policy, will be given cause to worry about inflation of the coin supply?
I understand that anyone who buys Bitcoin pre-fork has nothing to worry about, ostensibly - since they will own coins on both/all forks, but what about future buyers? Again, I understand that those future buyers may simply disregard some chain or other, and buy into a particular chain but, Bitcoin is confusing enough to explain to people, without introducing additional risks (what if I buy into the wrong chain, what if this keeps happening, every few years - and will the chains be interoperable, on what chain should I ask people to pay me - both?).
I am quite happy for Bitcoin to be forked - it has been many times in the past. The difference on this occasion, is that it is proposed that there will be more than one coin claiming the title "Bitcoin" - a name that is now known by many people around the world, and understanding is growing of what it is.
Yes, there are altcoins, but their market caps, distribution and depth of their order books are completely unlike Bitcoin.
I understand that it is a widely held belief that there is a coup going on, with regards to the blocksize limit - that it is some attempt to turn Bitcoin into something it was never intended to be.
It is not, in my opinion, a matter for debate as to whether by keeping the blocksize at 1MB, you would be changing Bitcoin from what it has thus far been.
My biggest concern, with larger blocks, is that it risks the stability of the network - events such as the 2015 Spam Attack 
would perhaps become cheaper to carry out, and if I were a miner with a large percentage of hash power, I could attempt something along these lines:
1. Generate a large number of very low fee transactions.
2. Make up my blocks as follows: Any and all transactions offering a fee exceeding x sats/bytes (much higher than I might otherwise expect, if a spam attack were not ongoing). Fill the rest of the block with processing my own spam, to reclaim the fees.
In the case that I win the block, the spam attack costs me nothing, and I have likely increased my fee revenue.
In the case that I do not win the block, and someone else mines my spam, it costs me less than the increase in my fee revenue.
In either case, users pay more, I make more, blocks do not get emptier.
Of course, like a good Blackjack card counter, I would include a certain amount of "coverplay" so as to make my actions seem random and difficult to prove, even under close examination 
I am not saying that smaller blocks eliminates problems such as this. But plans such as Segwit2x and BU, which intend to increase the blocksize considerably, which will increase demand for RAM and CPU cores in nodes considerably (during a spam attack, I have calculated that an 8MB block with segregated witness data, might require a node with 32GB of RAM - and that's assuming fees do not go down. If average fees are lower, a spam attack may well be able to, with enough will, push the mempool to 64GB, at which point the stability of the network may be severely under threat).
Even Dash, with their plan to scale up, acknowledge 20MB blocks would require 32GB RAM and Xeon Processors 
A move to 8MB blocks constitutes linear growth in maximum transaction throughput - in BIg O notation, O(n^2). To increase throughput to the levels where you can "buy a coffee" with Bitcoin, we need exponential growth - O(2N), with the N above the 2 (no LaTeX here).
I believe Bitcoin derives much of its value from its scarcity, and from decentralization. Both of these properties, as well as security, if you consider attacks such as the above described, are threatened by larger blocks.
Finally, I want to make the case to you that larger blocks will threaten the notion of increased privacy on the Bitcoin blockchain - there is a technology called Confidential Transactions 
that has been in the works for a few years now. It is estimated that processing a CF transaction will take a node considerably more CPU time to validate than a standard transaction 
, and it is my belief that if the blocksize has been increased to the equivalent of 20MB, and 25% of transactions were private (for example, you want to buy that coffee, but you don't want someone observing to be able to check the blockchain for your purchase, and figure out how much your mobile wallet contains), you would, if my understanding is correct - I'll happily be corrected, need a node to expend 15x as much CPU cycles to validate the first 15 of a 20MB block, vs a 1MB transactions, plus the remaining 5MB requiring 60x per MB; 315,000% more CPU power overall.
Perhaps this is an unfair comparison, so I will assume that the 1MB block contained 100% CF, and make the same calculations.
It would need 6,000% more CPU power than at present, and the 20MB block with 25% CF, over and above this amount, a 5,250% increase over that amount.
And this is where I believe CF, and with it the privacy it may be able to offer your transactions, may be threatened by increasing the block size, for a small linear gain in transaction throughput (we need a 15,000x increase to match Visa (and I think that's the minimum we should aim for), this would give us a 2,000% increase, we'd still need another 2,250% increase beyond that... - without CF, the increase is considerably smaller, I would estimate simply a 2,000% increase. Without extensive testing, specially crafted transactions may well find ways to take most miners offline, which would be a pretty strong argument not to add CF. 
I hope this sparks interesting discussion - I am open to hearing your views, and very aware that I don't know the full picture - 8 years after its creation, Bitcoin is vastly complex.
 A Bitcoin Spam Attack Post-Mortem: S(LA)ying Alive - Blockcypher Blog
 Bitcoin Spam Attack Stressed Network for at Least 18 Months, Claims Software Developer - Brave New Coin
 Hong Kong | Research and Planning (Dash) - HackerNoon
 Blockstream's Adam Back: Confidential Transactions started a blockchain privacy trend - IBTimes
 Greg Maxwell on Confidential Transactions @ Coinbase - Reddit discussion
 The Megatransaction: Why Does It Take 25 Seconds? - Rusty Russell's Coding Blog