Nobody can predict the future, but the past is not as mysterious; the number of shares already submitted during this round, at the time of deciding on a course of action, directly affects the estimates of what the eventual length of the round will be.
Umm - how can you start a sentence with a fact and end it with the exact opposite of that factual statement?
You've just stated correctly that you cannot predict the future, but then said the past affects the future.
No he didn't. He said the past affects your estimation for the future.
I'll put it this way:
Once you have mined n shares, there is absolutely no change in the probability of finding a block in the next share than there was in all of the previous shares back to the first.
That is true. It is also obvious, which is why nobody is disputing it.
Secondly, regarding your copy of Roulo's suggestion that pools that pay based on share% mined are affected detrimentally by hoppers
(or: hoppers make more BTC by hopping)
Let me use the simplest way to disprove a theory: An example that fails the theory will show it to be false.
Take this statement from Roulo's document:
It means that with optimal strategy it is possible to gain on average 28% of ones hashrate by switching from the pool after 43.5% of the current difficulty number of shares have been contributed. Notice that the function is fairly flat and even after switching after λ = 1, one can gain a fairly respectable 22% of ones hashrate.
Thus stating that from 43.5% to 100% (λ = 1) there is a gain between 28% and 22%
"a gain between 28% and 22%" - going from 28% to 22% is a LOSS, not a gain.
Yet a simple example with 50% shows this to be false:
If you mine with a share% of 10% at a site for 50% of the expected time to find a block, then, your shares will be worth on average 5% instead of 10% (since your % will slowly drop, after you leave, to 5% (on average) until the block is found)
During this time you can go to another pool with the same hash rate and do the same thing ... and thus get a total of 10% (5% from each) ... which is what you would have got to start with - not anywhere near 20% extra ...
This is not correct. You cannot use the average number of shares (from any point) needed to find a block to determine the average length of a round from the start of the round given that the round is already in progress. This is the obvious point you made earlier.