Offer can contain multiple relays, so you can have redundancy on those in case a relay dies. 

Key, pointer, and relays are encoded in the string, so if any changes it's a new string/QR... Old one will work if it's just an update to the array of relays and the old contains a working one

Best to think of them like a URL with parameters 

If a pointer or key changes you can still listen for the old one and respond with a 403-like error code to direct clients to the updated one

06bc1a977d

 becomes a long-lived payment endpoint rather than just another way to encode an invoice.

Since it contains the service pubkey, relay hint and offer identifier, how do you handle rotation in practice? If a merchant needs to change the service key or relay, can an already distributed 

 keep working, or does the merchant need to redistribute a new one?

That seems especially important for physical QR codes or links that may stay in circulation for a long time.

AGORA

lightning

be-BOP now supports CLINK for Nostr-native Lightning payments

What interests me most here is that the `noffer` becomes a long-lived payment endpoint rather than just another way to encode an invoice.

Since it contains the service pubkey, relay hint and offer identifier, how do you handle rotation in practice? If a merchant needs to change the service key or relay, can an already distributed `noffer` keep working, or does the merchant need to redistribute a new one?

That seems especially important for physical QR codes or links that may stay in circulation for a long time.