When the Proximity Beacon API was first announced, the use case I had imagined was to create a system where beacon field replacement was simplified because the metadata retrieved by clients (attachments and key/value properties) were separate from the beacon hardware currently representing that data (essentially the AdvertisedId).
In my mind, the attachments and properties represented the beacon's role (Bus Stop X, Shop Front Door, etc.), but hardware could be swapped into that role as needed. Meaning if a beacon died and had to be replaced, one could easily use the API to register/activate a new AdvertisedId for the same role, and deactivate/decommission the old (dead) beacon hardware.
I am having trouble working out if this use case is actually possible with the current API. A beacon cannot be given a name when registering (it is automatically named to a version of its AdvertisedId), and the AdvertisedId is ignored in subsequent updates (so it cannot be changed).
The best I can tell, the only way to "replace a beacon in the field" is to activate a new beacon and copy over all the attachments/properties/etc. from the old instance. Have I misunderstood the separation of concerns in the API? Is the only way to create a beacon role to manage that outside the API? Beacon field replacement seemed like a core tenant of the design.
The Proximity Beacon API doesn't have the concept of creating "roles" or "logical beacons" that might encompass one or more hardware devices — the expectation is that developers and the like will do this themselves.
The good news is that this really isn't that difficult — copying around data is also pretty trivial. None of the data structures or bits of information in the API are terribly complex so duplicating them will only be a line or two of code in your deployment applications.
Indeed, it seems as though the possible use cases for beacon registration data are so varied and many that the API was just kept as simple as possible to allow all of them.