One side argues that since bech32(m) addresses inherently function as a key-value pair, where the Human Readable Part (HRP) acts as the key and the subsequent characters as the value, adding an additional key for them under BIP21 is redundant. This redundancy not only complicates wallet software, which must now recognize addresses in two formats, but also overlooks a potential benefit of reducing QR code size, albeit this is considered a secondary advantage.

On the other hand, the counterargument acknowledges that while bech32(m) addresses do encapsulate a form of key-value structure, the complexity of parsing multiple addresses and parameters such as comments, amounts, and lightning information remains unaffected by this format. Therefore, simplifying address identification to a search for a preferred HRP or key-value protocol doesn’t significantly alter the overall parsing challenge. Moreover, there's an emphasis on the importance of not overly relying on bech32(m) for future address types, suggesting a flexibility towards adopting new standards as they emerge. Despite this, the current standardization of bech32(m) across Bitcoin and Lightning networks is acknowledged, along with its utility in addressing existing types without a BIP21 extension key efficiently. The discussion suggests a compromise that while special consideration for bech32(m) might be reasonable, it's critical to maintain support for new address types through key-value pairs, ensuring adaptability and forward compatibility.