Different changes have different reasonable switch criteria.
I can see your point and I admit this is the downside of my protocol, having said that, the protocol itself can be upgraded at any point by the same method.
Defining it in advance would constrain behavior without any advantage that I can see.
Currently if we upgraded blocks to version 3 and made some change that causes the 0.9.1 client to reject them, my client won't warn me that I am using an incorrect version. Instead it will carry on regardless and false chain attacks can be made.
I am a firm believer that protocols should be made to be as unambiguous as possible. The idea of having a block version field which is valid as long as it is not 0 or 1 seems rather stupid to me. In future instead of a nice
if version = 4 then do this
structure we will have a
if version = 4 and block height > n then do this
. This may be a rather cosmetic point but at the moment (correct me if I am wrong) there are no unit tests to test if alternative bitcoin implementations accept blocks with versions greater than 2 and if a programmer were to miss that small detail it could open up the opportunity to fork the network.
Your suggestion also presupposes a single sequential line of changes.
I can't see how changes can be non sequential without causing the network to fork. The one problem with my protocol is if there are two opposing changes proposed at the same time, nobody would know which change the new odd block version numbers represents.