The current state sees the coinbase witness value defaulting to all zeroes, a behavior stemming from Bitcoin Core without any consensus rules mandating this setup. This scenario leaves room for potential adjustments, such as fixing the coinbase witness to a specific value like "00000000height" or evolving it into a merkle tree structure where the left-most commitment must be "000000height." However, these suggestions bring forth concerns regarding the flexibility and future-proofing of the network.

There's an acknowledgment of the technical challenges that accompany the idea of introducing additional commitments into the coinbase witness. One significant hurdle is maintaining compatibility with existing nodes in a manner that doesn't necessitate a hard fork. The introduction of a second commitment could create validation issues for nodes only equipped to handle the first, unless a mechanism is developed to provide a full merkle-path to all but the most recent commitment, essentially requiring the publication of all leaf commitments in each block. This approach, though not incompatible with a soft-fork, would necessitate a peer-to-peer (P2P) protocol extension.

Furthermore, there's a consideration of the temporal aspect related to implementing new rules within the blockchain framework. Introducing rules that wouldn't take effect for decades poses a risk of inadequate implementation or complete neglect, potentially leaving future generations to address unforeseen complications. A comparison is drawn to the Y2K issue, highlighting the dangers of deferred action on technological standards. It suggests that for simpler modifications, a preparatory period of a couple of years might be more appropriate, aligning with the operational lifecycle of mining equipment and enabling current developers to implement and utilize these changes within their active careers. This perspective underscores a desire for timely improvements that facilitate easier access to block height information, avoiding reliance on complex scripts.