In contrast, some of your conclusions or narrative seem to be wrong. For example it has been clearly demonstrated that your strong narrative against Minisketch and some of your support points were (either intentionally or not) completely misleading and/or plainly wrong.
the thing is i see the big picture.
EG
issue: with bandwidth in relation to sending transactions so that users have them before a block is transmitted
reason: so that a block can be compact and users then dont need to grab transactions after compact block
instead of thinking of bigbox solutions that solve the whole issue. devs waste months and years on "exclusive" things that only handle a small offering, and only a offering for people who choose to use it. while not solving the broader big picture problem for the whole network
EG minisketch does not ensure nodes have every VALID transaction so that when a block arrives it can quickly validate a block without delay.
all because devs let users have configurable settings to play around and cause bottlenecks by being biased against certain transactions. thus ending up needing to retransmit transactions, causing delays in propagating blocks... all for the sake of 'user choice' which does affect other people (imagine the '8 degrees of separation theory' playing a game of chinese whispers)
if core want to be the defacto full node and network security offering the most efficient node that has least chance of block propagation latency.. then be a full node. take out all the funk that reduces a core node from being a full node. take out the user configurable stuff that can cause resends and latency. then you will find that resends and latency dont happen by default
if some users cant handle being a full node then they have the choice of electrum and other spv/litenodes
....
my other issue is how core devs dont want other teams to offer a full node option.. (unless the other team are actually colleagues/buddies)
take luke Jr's mandated follow core rules or get "f**k off" the network (UASF(it was actually a MCHF:mandated controversial hardfork)) or what greg would call a bilateral fork
take greg also loving the idea of hard forks if core dont get their way and others are trying to offer something different ON THE NETWORK
What you are describing is what
I and others call a bilaterial hardfork-- where both sides reject the other.
I tried to convince the authors of BIP101 to make their proposal bilateral by requiring the sign bit be set in the version in their blocks (existing nodes require it to be unset). Sadly, the proposals authors were aggressively against this.
funny part about the whole 2016-17 saga is that if core actually went with a segwitx2. it would have activated segwit much sooner.. and without the august hard fork
funny part is all the drama of core pretending to delay things to avoid a hardfork, ended up with one happening anyway due to their one direction, push it till its forced, no consideration for the community, no compromise to find a middleground mindset
if core actually listened and actually compromised some of cores demands to meet communities wishes.. core would have got segwit sooner and the community would have got more legacy utility.
and last funny part. with the now 95% core dominance. there is no actual reason to keep the witness scale factor in play, as there is not a controversial enough diversity of nodes to cause issues.. i find it funny because the august 1st event could have ben utiiised better to get rid of the (hidden by witness scale factor) 1mb allowance area completely. thus letting both legacy and segwit actually both function and both have full access to upto 4mb..
but no.. they done a half assed job because they have a roadmap that goes against opening utility on the network, because they need people to move over to LN so that greg and lukes investors can make some returns