Last year Qntra reported on BIP-65 which adds a new opcode OP_HODL which prevents nLockTime transactions from being double spent before the nLockTime threshold is reached on the Blockchain. Miners following the developers of the "Core" Bitcoin client have been adopting BIP-65, with approximately 25% of the last found blocks claiming to be ready for the soft fork on the version string in the block header. If or when BIP-65 is triggered, it may spell trouble for Mike Hearn's Bitcoin-XT due to deliberate incompatibility.

Mike Hearn went on a tirade earlier this year on the mailing list in midst of the hard fork missile crisis revolving around the block size, stating he does not support BIP-65. He offered (archived):

There is *no* consensus on using a soft fork to deploy this feature. It will result in the same problems as all the other soft forks – SPV wallets will become less reliable during the rollout period. I am against that, as it's entirely avoidable.

Make it a hard fork and my objection will be dropped.

For this reason BIP-65 code was never merged into Bitcoin-XT, thus its implementation of BIP-101 would produce nothing but orphan blocks if an invalid BIP-65 transaction ends up in a BIP-101 miner's mempool:

15:54 < jl2012> yes, so it's an attack as BIP101 doesn't really support BIP65. Even
worse, if you mine BIP101 blocks with invalid BIP65 tx, your block will be orphaned
if the softfork is activated (75%)
15:54 < jl2012> And by that time, the network may fork, just like what happened
during BIP66

Mike Hearn seems to want nothing more than to have the Bitcoin network hard fork, forcing users to agree to new consensus rules. It has become quite clear, the motivation behind his arguments are nothing more than a way to cover up a malicious attempt to hijack the Bitcoin network.