Hi alicexbt,
As far as I understand things, I believe the whole notion of a MUST_SIGNAL state is misguided today. Please correct me if I'm misunderstanding something here.
Back when BIP8 was first proposed by Shaolin Fry, we were in a situation where many existing clients waiting for segwit signalling had already been deployed. The purpose of mandatory signaling at that point in time was to ensure all these existing clients would be activated together with any BIP8 clients.
However, if such other clients do not exist, the MUST_SIGNAL state no longer accomplishes its purpose. Going forward, I think there is little reason to expect such other clients to exist alongside a BIP8 deployment. If everyone uses a BIP8 deployment, then there are no other clients to activate. Alternatively, Speedy Trial was specifically designed to avoid this parallel deployment for the reason that several people object to allowing their client's non-BIP8 activation logic to be hijacked in this manner.
Now I understand that some people would like *some* signal on the chain that indicates a soft-fork activation in order to allow people who object to the fork to make an "anti-fork" that rejects blocks containing the soft-fork signal. And while some sort of mandatory version bit signaling *could* be used for this purpose, we do not *have* to use version bits. We also don't need such a signal span over multiple blocks. Indeed, using version bits and signaling over multiple blocks is quite bad because it risks losing mining power if miners don't conform, or are unable to conform, to the version bits signal. (Recall at the time taproot's signaling period started, the firmware needed for many miners to signal version bits did not even exist yet!).
A soft-fork signal to enable an "anti-fork" only needs to be on a single block and it can be almost anything. For example we could have a signal that at the block at lockin or perhaps the block at activation requires that the coinbase must *not* contain the suffix "taproot sucks!". This suffices to prepare an "anti-fork" which would simply require that the specified block must contain the suffix "taproot sucks!".
Anyway, I'm sure there are lots of design choices available better than a MUST_SIGNAL state that does not risk potentially taking a large fraction of mining hardware offline for a protracted period of time.