Further up in the thread @GrahamS outlines a use case that would "require" late registration.
While it would be possible to just register dummy variables with generic names and repurpose them for whatever need once the "role" of the device or the kind of its sensors in a dynamic system has been established, but the possibility of doing all of this after that - or whenever the role changes - has its charm.
Also further up I wrote this
and even further up
So the idea would be to add some way to "instruct" the cloud side to pull the new list of vars/fns from the device (e.g. similar to the spark/device/... events to "instruct" the cloud to send some data) and also tell the device to "volunteer" (as you worded it) - e.g. via an instruction that'd be placed in a handler (again like the spark/device/... events).
Sure this could be handled transparent directly in system firmware, but since the framework of these events already exists, this way seemed to be the easiest to be extended in that way.
One option for working around this that I've found (although not usable for all applications), is to use a retained setup flag to specify the role, then do a System.reset() call to restart the Photon. The setup flag is kept across the reset and checked on startup, and then only the 'role specific' code runs from that point on. I can then clear this by interrupting the power supply to get back to a fresh state. For more persistence you could instead use EEPROM, which would let you keep the role assignment across a power outage.
