This contrasts with more niche use-cases like Ordinals or Taproot Assets, which may not be suitable as BIP material given their limited application scope. The V3 proposal, designed for contracting protocols and prominently for lightning network operations, approaches the broad usage seen with BIP-125 but isn’t quite as widespread.

However, there are significant issues connected to the implementation and understanding of these standards, such as lack of awareness about additional rules implemented by Core beyond the original BIP-125 specifications. An example cited is RBF Rule 6, where ignorance of its existence led to errors in the safety analysis of a protocol. Similarly, the documentation for V3 is inadequate, missing critical components like practical use-case examples, and lacks consensus on how Lightning channels should deploy V3 transactions, including the trade-offs involved. Such gaps have led to erroneous claims about the advantages of V3 transactions, particularly regarding their effect on transaction pinning vulnerabilities.

The author suggests that while a formal BIP might not be necessary for V3, it would benefit from an engineering process with thoroughly analyzed use-cases. A key takeaway is that mempool policy should be backed by dynamic documentation that evolves to reflect real-world implementations and explains the rationale and compromises inherent in those policies. This need for "living documentation" may surpass what the BIP process can offer, indicating a potential limitation of the BIP framework in keeping up with the practical realities and complexities of Bitcoin’s evolving landscape. For further insight into the V3 transaction pinning issue, the author provides a link to an in-depth analysis (https://petertodd.org/2023/v3-txs-pinning-vulnerability).