@epriestley: I can help with testing and validating on elasticsearch, if that helps at all.

Actually, we can go one step further than D19686, I think.

We have a general initialization order issue where a later config file may define a load/--library setting that includes a typed Setting/Config object for a setting value in an earlier file. So I think this needs to happen in several phases:

T11934 is not exactly adjacent here, but I suspect it feeds into some other incidental goals and may provide a workaround for some things which get removed.

I'm looking toward making arc alias work in the general case again, but the big thing this is blocked by is reliance on config.

As a note, we make quite a bit of use of --arcrc-file currently to "handle" multiple people working as root on dev VMs, but we can probably migrate that over to --conduit-token anyway (although we're a way off hitting this, because as much as I want drafts, other people consider T4678: Support changelist-based SVN workflows in Arcanist and Differential critical and we're on a fork because of that.)

See T13098 and T13203.

I think we have no realistic way forward here. See T13201 for related things which are moving forward.

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.

In T9041#240610, @epriestley wrote:

"Disable User", specifically, is now granular.

Use cases we've seen FWIW: