To further elaborate:

Even when obtaining *all* users (without criteria) in a paginating fashion with user.query(), it's preferable to have this because it is cursor based and doesn't suffer from O(offset) performance characteristic which is bad enough to be a real problem for 10k+ users.

FWIW is something like user.edit on the table? We'd like to be able to pre-create users with specific information such as 'real name', and a particular external account linked.

I think T5953 is a better fit for that in the upstream.

After D15959, user.search should support "find all non-disabled human users", likely with parameters in this vein:

{
  "constraints": {
    "isDisabled": false,
    "isBot": false
  }
}

The method returns slightly less information than user.search did; open to adding more information but it sounds like you don't need it for this use case. Some old keys like uri and image might be better as dictionaries now, so they can return multiple URIs, multiple resolutions, etc.

These changes are live on this install:

• user.search

We can return more data easily if anything is missing, but I want to do that case-by-case and try to future-proof whatever format we're emitting so the "v3" API can last us for at least a few years. I don't have any specific additional changes planned, so pausing this for feedback.