- The BIP91 portion of the fork seems OK to me. There are some issues with timing, but since this is for miner coordination of segwit activation, and has little to do with other network users, it could be included as an option. (I'm a fan of adding options;plugins, etc. to Bitcoin... some others aren't.)

- This hard fork portion of the proposal is being deployed with "emergency" speed... even though there is not an emergency on the network today that I am aware of. If enacted, it will certainly result in two chains - and with no replay protection.. The results of this will be confusing - two ledgers with many transactions appearing on both and others appearing only on one.

- The BIP should be modified to provide evidence and justification for the timeline that is consistent with the level of risk the network would bear if it were enacted.

- The coercion used to drive production of this BIP is mired in a misinterpretation of BIP9 and sets a precedent for Bitcoin that may undermine the value prospect of all cryptocurrency in general. For this reason alone - even if all of the engineering concerns and timelines are improved - even assigning this BIP a number could be considered irresponsible.

- If you still want to code up a fork for the Bitcoin network, consider starting with Luke's hard fork code and changing the rates of growth as needed for your desired effect. Also you might want to read this first (code references are in there): https://petertodd.org/2016/hardforks-after-the-segwit-blocksize-increase . Plans are already underway for a hard fork, for reasons that have nothing to do with block size, but could include a timeline for a block size growth consistent with global average residential bandwidth growth.