See some discussion in D13777.

There is no "Create New Users" policy. The "Can Create (non-bot) Users" policy only controls access to the ability to create standard user accounts, given that you can already create new users. The only meaningful settings for this are "Administrators", "No One", or some subset of administrators.

We added this policy when building the Phacility cluster to prevent instances from adding new un-linked accounts (it is locked to "No One" in the cluster). Realistically, this feature probably only makes sense in the cluster, but it seemed like a small and quasi-general enough thing to add to the upstream that it was reasonable, even though it really just enables Phacility clustering.

I'd eventually like to fully modularize administrator capabilities and give them the current capabilities as defaults, but allow you to change them (for example: let you set the policy for who can edit an application to some other set of users). However, this is a lot of work.

In T9041#240610, @epriestley wrote:

"Disable User", specifically, is now granular.

@epriestley: This might add unwanted code complexity, but has it been considered not to allow a user with Disable User rights to disable admin accounts if the user is not admin themselves? Imagine an attacker taking over an account with Disable User rights and then disabling (locking out) all other accounts with such rights, until someone with shell access can be reached.

I don't currently plan to make "Disable User" any more granular than it is. If you have a use case where you want multiple administrator levels and to allow administrators at a certain level to act downward but not upward, you might be able to do something like have an enforcer-bot account which users can instruct to disable one another. The enforcer-bot itself could act via the API.