The author mentions that more discussion would be helpful, particularly regarding flexibility around tallying window size to ensure compatibility with BIP9 for a certain version bit, if desired. The author argues that the point of BIP9 is to allow nodes that do not know about an upgrade to still have a functional state machine and suggests that having unspecified variables would prevent this from happening. However, the author clarifies that the basic design of the state machine would remain the same, and each signaling bit would effectively run its own unique state machine instance. The author proposes that an initial implementation could provide all of this in compiled code, but a more sophisticated implementation would push the signaling configuration into an external configuration file that adheres to a fixed format and could easily be adapted and shared between implementations. The author argues that old nodes would miss the data to transition to certain states without these variables in the actual BIP, but also suggests that this proposal does not fundamentally change the current situation for old nodes. The author proposes the idea of having three default sets of properties for the 30 bits available and suggests that certain bit ranges could have conventions placed on how they are used. However, the author does not see the point of the BIP doing this, although it could suggest examples. The author prefers if the BIP's reference implementation provides strict BIP9 compatibility in configuring the bits with 2016 block windows evaluated in strict synchronicity with BIP9 and default 95% thresholds. In reality, most bits are unused today, and someone wishing to use a bit for a feature deployment would announce so publicly in a BIP and release an implementation that is suitably configured. Others wishing to provide compatibility with that feature would adjust their code and bip-genvbvoting configuration files accordingly.