I am not going to say that an individual block time shall be perfectly valid. The only restriction that the top of a main chain shall not end in remote future.
This is just the problem, "remote future" is effectively undefined because "current time" which it is relative to is effectively undefined. The allowed values for "remote future" would have to be quite remote, and quite broad. As such, I don't feel that this would accomplish what you think.
Specifically, the problem is that the allowed range of valid wall clock times has to be somewhat large relative to the block interval, or problems quickly arise. However, a good balance is important because making it too large makes traditional time warp based 51% attacks more likely to success. I agree that we might possibly want the range to be smaller for various reasons, but disagree that it needs to be biased toward the past and in fact think doing so might be very problematic.
There is no error accumulation issue then and perfect time synchronization is not critical.
Agreed on both points. The definition of "perfect" has to be very very loose though.
Even if some client will accept a block from future he will not be able to compete with miners who accepted and start mining from earlier blocks because his chain will be longer than their chain.
Until if/when wall clock catches up to him, of course. I agree that part of this is good for all.
Now we have transaction acceptance criteria that it should be included in a chain longer than say 10 blocks. We can also add that those blocks shall not be from the future.
Not sure I follow this bit, please can you rephrase?
EDIT: did you mean on confirmations, not on acceptance?