I may try to compile the version that only includes the block increase and not Mike's other changes, will see how that goes when I get started on it.
That won't work after a successful fork; XT will ignore the chain consensus rules (longest chain with highest POW wins). This means that if you dislike XT's future direction, a hard fork is no longer possible, the development team are in charge of which chain prevails, not miners.
That's not quite correct. The developers could add code that gives them 10% of each block reward and you'll find that most users, miners, services, etc. will go tell them to fork off, refuse to run any client with that code, and those devs will merely have wasted their time. Checkpointing (which I think you're alluding to, as Mike has mentioned in an interview once that this could be an option in case the chain goes back and forth) doesn't help either if people don't run the code that adds (or polls for) these checkpoints. Forks are also always a possibility - this doesn't depend on developers in any way, only on what the network deems as being valid, which in turn depends on the code the nodes run. Whether that fork would find success depends entirely on the merits of the fork.
Those 'other changes' currently in XT also don't rely on the fork or the BIP101 code at all. Nodes could already be running with those changes in place and in effect (XT nodes do), and you'd never know unless you did an analysis of the node's behavior.
