Yeah, nobody would use it, so probably not so dangerous, but I think by the same token not particularly useful. No strong opinion here either (though my preference is to have it not getattr from local_settings), but I'll explain a bit since it might be interesting/useful background for future decisions.

    For testing purposes, to keep testing models from syncing with production models

It's not a robust way to keep test models from syncing, since many will still sync normally, and others will sync but get assigned different UUID's (so we end up with duplicates). Also, for automated testing, we don't want to have to hard-code stuff into local_settings (since it should only be active during the tests) -- we're now already monkey-patching the settings to change cache paths etc, which may be the necessary approach for that sort of thing.

    When we duplicate this app to server content for other partners, we could test changes to the namespace by setting local_settings.

Hmm, I think we'd probably still want to use our main ROOT_UUID_NAMESPACE for phase 2 customizations, as long as we're keeping the models fairly similar and plan to sync to the same place.

    If we ever wanted to set up a duplicate system, could just tweak the namespace in local_settings.

Even for a completely duplicate system, there would be no need to change this value; UUIDs would be unique across the systems anyway, because a) device UUID's are a function of the public key, which is uniquely generated, and b) all other models are derived in some way from the device's UUID.

It might also be safer to have the ROOT_UUID_NAMESPACE be a hard-coded constant, instead of showing it as a function of "https://kalite.adhocsync.com/", since it doesn't actually have anything to do with the URL, which could lead to confusion (it was just an easy way to get a constant UUID).