the reality was that 2x would never actually have got adopted as core designed and implemented code to REKT it as soon as segwit(x1) got its threshold
And don't forget the part where the /btc1 devs pulled the plug in November 2017. It's kinda hard for forks to gain adoption if the devs abandon them completely. Another potential barrier to adoption is if your chain potentially stalls at block 494782 because there was a bug and there weren't nearly enough people testing the code to notice. But yeah, definitely all Core's fault again.
Keep in mind, I'm saying this as someone who supported SegWit2x as a viable option. I was genuinely interested in seeing how it was going to unfold with what looked to be a looming three-way fork and believed SegWit2x had the potential to outperform BCH in terms of market share and overall usage. But ultimately, I recognise there wasn't adequate support from non-mining nodes and there's little doubt it would have been more centralised. Perhaps in future, this may change. You might call it "REKT", but some might call it "users not feeling comfortable being pressured into a change they didn't support". It's all a matter of perspective and opinion. But the one thing that should be abundantly clear by this point is that supporters of SegWit2x failed to present a convincing enough argument (and also working code, but that's beside the point).
You support the group behind the NYA which tried to undermine the community? Ok, that's no problem for me, it failed at any rate.
i don't support any groups, i support proposals. if we start supporting "groups" then we are effectively centralizing bitcoin to that group. it doesn't matter who they are and what they have done so far. you have to check the code itself.i don't claim to be an expert though. but with little knowledge that i have i checked out different proposals regardless of who started them.
My stance is pretty similar. It's difficult to find a way to summarise it succinctly. Beyond what you've said, I'd add that there's a balance to be struck between supporting proposals that we might personally agree with, but not getting so attached to them that it potentially clouds our judgement to the fact that other users may be unlikely to accept that proposal because it potentially hampers their own usage and needs.
People can certainly try to argue that "no change" could be hampering their usage and needs when it comes to topics like throughput, but if you can't get what you want without taking away what other people already have (and deem valuable, like decentralisation), it shouldn't come as a surprise when those other people decide that what you want is not very good. Why should they give up what they have for what you want?
I might, for example, think a given proposal is the greatest thing in the world, but if other users don't agree and won't get behind it because it has a negative impact on them, I then have two options. Either to respect their choices, go with the flow and accept the current consensus. Or to take the plunge on a minority fork that then has to fight for survival in the open market. I might mistakenly believe I have the third option to delay or block a different proposal those other users support by running code that doesn't support it. But I could potentially find that option fails if those other users deem my code invalid and remove me from their network, which is their right.
If an individual does believe in a proposal strongly enough and there isn't wide support for it, they might suddenly find the need to be willing and prepared to move forward as a fork without expecting to somehow inherit BTC's userbase, hashrate, adoption, etc. It's not like you can put a gun to the heads of those securing the chain and make them tag along. It's up to other users if they want to join you or not. It's strange how often people forget this and just vehemently nail their colours to the mast without compromise. They think if they shout loudly and often enough that it might change things. But it doesn't.