One such idea involves the implementation of bundled payments within the spec, allowing invoices to include multiple preimages and amounts. This concept primarily targets applications like submarine swaps and Just-In-Time (JIT) channels which necessitate the prepayment of mining fees for non-custodial exchanges. Detailed explanations of this proposal are accessible through provided links, indicating a community-driven effort to expand BOLT12's utility in practical scenarios.

Another significant point of discussion is the lack of a defined prefix for invoices within the BOLT12 spec. The suggestion to adopt the lni prefix, already informally utilized by Core Lightning (CLN) for specific Remote Procedure Calls (RPC), aims to fill this gap. This prefix is demonstrated in CLN's documentation for commands such as fetchinvoice and pay, highlighting an emerging standard within the community despite the absence of formal specification. These examples underscore the necessity for a more structured approach to invoice prefixes to facilitate clearer communication and interoperability across implementations.

Further examination of BOLT12 suggests that certain proposed features might be more appropriately introduced as bLIPs (BOLT-like Improvement Proposals) rather than direct amendments to the existing specifications. This perspective emphasizes the importance of maintaining the core operations of BOLT12 while offering optional enhancements that users can adopt based on their needs. One proposal detailed at delvingbitcoin.org explores the incorporation of trusted contacts without disrupting the foundational aspects of BOLT12, illustrating a method by which the protocol's capabilities can be expanded in a backward-compatible manner.

Recent progress includes the merger of BOLT12 into the main repository, signaling the start of its practical application and opening discussions on further improvements. Among these is the proposition to add a user field in the invoice_request and an optional boolean refund_invoice_required field for offer writers, facilitating automated refunds and addressing operational constraints through features like offer_max_amount. Additionally, the introduction of an expiration mechanism for invoice_requests is suggested to manage offer lifecycles more effectively, ensuring transaction relevance within specified timeframes.

These collective efforts towards refining BOLT12 reflect a community-driven process, inviting feedback to shape its evolution in meeting the diverse demands of real-world usage.