That URL-with-parameters analogy makes it much clearer.

Multiple relays solve the redundancy concern nicely, and keeping the old endpoint alive long enough to redirect clients when the key or pointer changes seems like a practical migration path.

I was initially thinking of the nOffer more like a permanent payment address, but it makes more sense to think of it as a portable service endpoint with an explicit lifecycle.

Thanks, that answers exactly what I was trying to understand.

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