If I configured the same IDs into every node, and configured an application that got those packets and responded with a downlink of a new (unique) id and keys which the device then saved to flash & restarted itself…how offensive would that be?
To an extent, you are re-inventing the already problematic OTAA scheme, only with additional problems.
One key one is that you have no way of knowing which dynamically assigned ID corresponds to which physical node or node location. That’s an absolute dead-end showstopper for most usage. Maybe you can think of something where it wouldn’t be…
Another problem is that you have difficulty telling original tries apart from retries - remember, it’s not just the uplink path where a signal can be lost, you can also get a great uplink, produce a response and record it in your device database, but have the packet not make it intact back down to the node.
And even if you solve those problems, you’ll likely be on your own outside the LoRaWAN spec, as having traffic from different nodes sharing the same key set is utterly unworkable due to the restrictions against re-use of frame counter values. That’s not to say LoRaWAN is perfect - it actually has some fairly serious issues. But if you are going to step outside of the standard, you should first have a very clear idea what you are doing and why - and bear in mind that if you are no longer doing compliant LoRaWAN, you are no longer doing TTN either…
Ultimately it’s hard to defend the avoidance of an at least locally assigned unique ID on any other grounds than privacy. And while privacy is a real concern, since a node will have an ID once joined to a LoRaWAN network anyway, the best compromise is probably what networks like TTN do - require a pre-assigned unique ID, but let the end user re-assign it anytime they like.
I can also imagine a variant where I do have a unique ID per device but have a master-config application that dynamically reconfigures the OTAA keys based on those IDs e.g. I know I sold device 1234 to Client A, so hand out Client A’s keys to it after it connects the first time.
Various identity replacement schemes are actually done.
Though it’s extremely hard to get closed source LoRaWAN right. If you’re going to make customers play with your system rather than have the option of building the firmware or loading their keys with a cable, then you really have to commit to supporting you closed firmware.
Customers will in the first five minutes find design bugs that successfully hid from five months of testing.