It is pointed out that while both approaches require changes, exposing Bolt 12 invoices is seen as less cumbersome, needing fewer code alterations and less additional work on specifications. This approach would necessitate making certain fields, like those referencing the offer ID, optional instead of mandatory.

There's an acknowledgment of the importance of estimating the size of the BOLT11 invoice with blinded paths, a task that remains relevant even with the adoption of BOLT 12 invoices. The conversation also touches upon the strategic approach of focusing on refining a small component thoroughly before moving onto other aspects. This method is contrasted with working on multiple components simultaneously, which could lead to a lack of refinement and potentially prolong the overall deployment timeline.

User experience (UX) considerations are central to the debate, especially regarding how wallets handle offers and invoices. Current practices among wallets, such as Phoenix/Eclair, are examined in terms of their handling of encoded offers, including user notifications and the management of background processes. The need for wallets to smoothly transition between being presented with a BOLT11 invoice or an Offer is underscored, drawing parallels with the existing capability of wallets to manage AMP invoices.

Furthermore, the discussion delves into the potential benefits of using offers for L402, a protocol related to invoice negotiation. While initially it seems that Offers might not play a significant role in L402 due to its structure of providing an invoice directly via HTTP response, the consideration of using blinded paths within this framework is discussed. The argument against short-term "hacks" or intermediate solutions is made, emphasizing the long-term efficiency and reduced maintenance costs of implementing more comprehensive solutions from the outset.

Finally, the correspondence clarifies that employing existing extension vectors in current invoice formats for innovations like blinded paths should not be considered a hack. This strategy allows for the integration of new functionalities while maintaining the integrity of the existing system architecture. The distinction between the encoding/presentation layer and the core components, such as the onion/routing layer, is highlighted, pointing out a common misconception that conflates protocol packaging with the underlying technical mechanisms.