For the reasons listed
here(https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki#Motivation)
you should have it so that the HF can not lock in unless the existing
BIP141 segwit deployment is activated.

The biggest issue is that a safe HF is very unlikely to be able to be
coded and tested within 6 months.

On Sun, May 28, 2017 at 8:18 PM, CalvinRechner via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> This proposal is written under the assumption that the signatories to the
> Consensus 2017 Scaling Agreement[1] are genuinely committed to the terms of
> the agreement, and intend to enact the updates described therein. As such,
> criticisms pertaining to the chosen deployment timeline or hard fork upgrade
> path should be treated as out-of-scope during the initial discussion of this
> proposal.
>
> Because it includes the activation of a hard fork for which community
> consensus does not yet exist, this proposal is not likely to be merged into
> Bitcoin Core in the immediate future, and must instead be maintained and
> reviewed in a separate downstream repository. However, it is written with
> the intent to remain cleanly compatible with future network updates and
> changes, to allow for the option of a straightforward upstream merge if
> community consensus for the proposal is successfully achieved in the
> following months.
>
>
> <pre>
> BIP: ?
> Layer: Consensus
> Title: Compatibility-oriented omnibus proposal
> Author: Calvin Rechner <calvinrechner@protonmail.com>
> Comments-Summary: No comments yet.
> Comments-URI: ?
> Status: Draft
> Type: Standards Track
> Created: 2017-05-28
> License: PD
> </pre>
>
>
> ===Abstract===
>
> This document describes a virtuous combination of James Hilliard’s “Reduced
> signalling threshold activation of existing segwit deployment”[2], Shaolin
> Fry’s “Mandatory activation of segwit deployment”[3], Sergio Demian Lerner’s
> “Segwit2Mb”[4] proposal, Luke Dashjr’s “Post-segwit 2 MB block size
> hardfork”[5], and hard fork safety mechanisms from Johnson Lau’s
> “Spoonnet”[6][7] into a single omnibus proposal and patchset.
>
>
> ===Motivation===
>
> The Consensus 2017 Scaling Agreement[1] stipulated the following
> commitments:
>
> • Activate Segregated Witness at an 80% threshold, signaling at bit 4
> • Activate a 2 MB hard fork within six months
>
> This proposal seeks to fulfill these criteria while retaining maximum
> compatibility with existing deployment approaches, thereby minimizing the
> risks of a destructive chain split. Additionally, subsequent indications of
> implied criteria and expectations of the Agreement[8][9] are satisfied.
>
> The proposed hard fork incorporates a legacy witness discount and 2MB
> blocksize limit along with the enactment of Spoonnet-derived protectionary
> measures, to ensure the safest possible fork activation within the
> constraints of the requirements outlined in the Scaling Agreement.
>
>
> ===Rationale===
>
> To the extent possible, this represents an effort at a best-of-all-worlds
> proposal, intended to provide a common foundation from which all
> mutually-inclusive goals can be achieved while risks are minimized.
>
> The individual constituent proposals include the following respective
> rationales:
>
> James Hilliard’s “Reduced signalling threshold activation of existing segwit
> deployment”[2] explains:
>
>> The goal here is to minimize chain split risk and network disruption while
>> maximizing backwards compatibility and still providing for rapid activation
>> of segwit at the 80% threshold using bit 4.
>
> Shaolin Fry’s “Mandatory activation of segwit deployment”[3] is included to:
>
>> cause the existing "segwit" deployment to activate without needing to
>> release a new deployment.
>
> Both of the aforementioned activation options (“fast-activation” and
> “flag-day activation”) serve to prevent unnecessary delays in the network
> upgrade process, addressing a common criticism of the Scaling Agreement and
> providing an opportunity for cooperation and unity instead.
>
> Sergio Demian Lerner’s “Segwit2Mb”[4] proposal explains the reasoning behind
> linking SegWit’s activation with that of a later hard fork block size
> increase:
>
>> Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2MB block
>> size hard-fork activated ONLY if segwit activates (95% of miners signaling
>> ... to re-unite the Bitcoin community and avoid a cryptocurrency split.
>
> Luke Dashjr’s “Post-segwit 2 MB block size hardfork”[5] suggestions are
> included to reduce the marginal risks that such an increase in the block
> size might introduce:
>
>> if the community wishes to adopt (by unanimous consensus) a 2 MB block
>> size hardfork, this is probably the best way to do it right now... Legacy
>> Bitcoin transactions are given the witness discount, and a block size limit
>> of 2 MB is imposed.
>
> Johnson Lau’s anti-replay and network version updates[6][7] are included as
> general hard fork safety measures:
>
>> In a blockchain split, however, since both forks share the same historical
>> ledger, replay attack would be possible, unless some precautions are taken.
>
>
> ===Copyright===
>
> This document is placed in the public domain.
>
>
> ===Specification===
>
> ###Proposal Signaling###
>
> The string “COOP” is included anywhere in the txn-input (scriptSig) of the
> coinbase-txn to signal compatibility and support.
>
> ###Soft Fork###
>
> Fast-activation (segsignal):  deployed by a "version bits" with an 80%
> activation threshold BIP9 with the name "segsignal" and using bit 4... [with
> a] start time of midnight June 1st, 2017 (epoch time 1496275200) and timeout
> on midnight November 15th 2017 (epoch time 1510704000). This BIP will cease
> to be active when segwit is locked-in.[2]
>
> Flag-day activation (BIP148): While this BIP is active, all blocks must set
> the nVersion header top 3 bits to 001 together with bit field (1<<1)
> (according to the existing segwit deployment). Blocks that do not signal as
> required will be rejected... This BIP will be active between midnight August
> 1st 2017 (epoch time 1501545600) and midnight November 15th 2017 (epoch time
> 1510704000) if the existing segwit deployment is not locked-in or activated
> before epoch time 1501545600. This BIP will cease to be active when segwit
> is locked-in. While this BIP is active, all blocks must set the nVersion
> header top 3 bits to 001 together with bit field (1<<1) (according to the
> existing segwit deployment). Blocks that do not signal as required will be
> rejected.[3]
>
> ###Hard Fork###
>
> The hard fork deployment is scheduled to occur 6 months after SegWit
> activates:
>
> (HardForkHeight = SEGWIT_ACTIVE_BLOCK_HEIGHT + 26280)
>
> For blocks equal to or higher than HardForkHeight, Luke-Jr’s legacy witness
> discount and 2MB limit are enacted, along with the following Spoonnet-based
> improvements[6][7]:
>
> * A "hardfork signalling block" is a block with the sign bit of header
> nVersion is set [Clearly invalid for old nodes; easy opt-out for light
> wallets]
>
> * If the median-time-past of the past 11 blocks is smaller than the
> HardForkHeight... a hardfork signalling block is invalid.
>
> * Child of a hardfork signalling block MUST also be a hardfork signalling
> block
>
> * Hardfork network version bit is 0x02000000. A tx is invalid if the highest
> nVersion byte is not zero, and the network version bit is not set.
>
>
> ===Deployment===
>
> Deployment of the “fast-activation” soft fork is exactly identical to
> Hilliard’s segsignal proposal[2]. Deployment of the “flag-day” soft fork is
> exactly identical to Fry’s BIP148 proposal[3]. HardForkHeight is defined as
> 26280 blocks after SegWit is set to ACTIVE. All blocks with height greater
> than or equal to this value must adhere to the consensus rules of the 2MB
> hard fork.
>
>
> ===Backwards compatibility===
>
> This deployment is compatible with the existing "segwit" bit 1 deployment
> scheduled between midnight November 15th, 2016 and midnight November 15th,
> 2017.
>
> To prevent the risk of building on top of invalid blocks, miners should
> upgrade their nodes to support segsignal as well as BIP148.
>
> The intent of this proposal is to maintain full legacy consensus
> compatibility for users up until the HardForkHeight block height, after
> which backwards compatibility is waived as enforcement of the hard fork
> consensus ruleset begins.
>
>
> ===References===
>
> [1]
> https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014380.html
> [3] https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki
> [4]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013921.html
> [5]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014399.html
> [6]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html
> [7]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013473.html
> [8] https://twitter.com/sysmannet/status/867124645279006720
> [9] https://twitter.com/JihanWu/status/867139046786465792
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev