This sounds 

> "True" password iterations as a non-configurable property across all distributed servers (i.e. we enforce some strong level of security).

It might still be nice to have it configurable, even if not high-lit as configurable to the admin. It should be some moderately high default, and typically left at that, but due to the huge variance in hardware speed, and potentially in account sensitivity, it would be nice to be able to bump it up even higher in some cases. But yeah, no big objections to having this fixed.

> disable the Settings.get setting for password iterations

The only reason I can see not to do this is if we want to allow it to auto-benchmark the local hardware's hashrate  (during installation) and set an appropriate number of iterations based on that. Though if we're going to start generating a local_settings.py file during installation, based on user choices, then it could just go in there anyway, and wouldn't need to use Settings.

In any case, we don't need to worry too much about backwards compatibility here, and can always augment this later (though I agree that not changing the meaning/name of settings later is definitely wise). One (infrequently occurring) thing to worry about is if users are created on a device with a newer version (running this code) and then synced to a device running an older version, since if those users then logged in on that device, they'd be using the larger number of iterations for every login, with no cache. But, infrequent, and not much we can do about it.