The implementers have acknowledged that forking the chain does not represent a performance improvement. The remaining objective is reduction of code complexity. However, a proposal to change the protocol must be considered independently of any particular implementation of the protocol. While BIP34 style activation may be complex in the satoshi code, it is not complex as a matter of necessity. Activation constitutes only a dozen lines of additional code in libbitcoin. In fact, these fork suggestions actually increase necessary complexity for any implementation that takes a rational approach to forks. Deleting rules from Bitcoin code is bad design since rules are never removed, they are added. A new rule to modify an old rule is simply a new rule and this is new and additional code. Thus, there are many opportunities to reduce satoshi code complexity in ways that do not impact the protocol. Once that is done, developers can talk about forking to reduce source code complexity. These proposals do not make development simpler for other implementations because they increase necessary complexity for any implementation that takes a rational approach to forks.In another message, the author suggests that conceptually, another way to deal with the issue is to hardcode a blockhash where blocks in a chain ending with that blockhash are allowed to not follow BIP65, up until that blockhash, and any blockchain without that blockhash must respect BIP65 for all blocks in the chain. This is called a softfork. It is suggested that this should be called an exemption hash - a particular blockchain is exempted from a soft-forked rule that would otherwise be enforced.