Or that 2-4-8 is a vastly different proposition (being as it stops at 8MB)
Surely the more pragmatic approach would be to see what the average connection and bandwidth availability is later when we're approaching 8MB and have the
option to keep going
if it's safe to do so?
I agree, but that's baked into a 2-4-8 cake anyway. If 8MB was reached as you say, then the option still exists via hard forking again. Except if you're running a post-fork XT network; the hard forking mechanism can't be used once Mike's proposed blockchain checkpoints get introduced.
(another mindless XT argument debunked; they constantly claim that hard forks are possible using the proposed XT codebase, when XT has been re-designed to prevent any further hard forks)
Just so I'm clear on how this 2-4-8 works, obviously we need a hard fork to get the ball rolling. Then going from 2 to 4 and from 4 to 8 doesn't require a hard fork, but going beyond 8 means we've made a guess about the future now and have drawn a line in the sand based on nothing more than a hunch?
From the very start of this discussion, people have repeatedly stated that we can't make assumptions about the future, so why are we assuming that 8 is as far as we should go? People argued that "kicking the can down the road" is the wrong approach, but taking a guess at a future limit and carving it in stone now is precisely that. We shouldn't view this as a temporary kludge, just in case the other predictions people are making about alternative methods of scaling don't pan out as planned. There's no sense in creating hurdles for the future when we don't need to. We should try to keep subsequent hard forks to an absolute minimum where possible.
And the checkpoints thing was an idea. A bad one, granted, but never implemented (or did I miss something?), so I don't see why it's still being picked at.