I'm going to go through a second time, but I think I found the most obvious strings to update. I'm wondering if those that aren't in the specs should be updated/rewritten, as well.

Restricting to an array seems less disruptive than disallowing PARAM_ISMULTI entirely. What additional tests are needed?

Patches are proposed on each extension. There are unrelated test failures on Workflows, BlueSpiceExtendedSearch, Checklists, ContentStabilization and MenuEditor.

Made edits across wikis; given the range of wikis and variety of pages across languages needing changes, encouraging communities to make associated edits.

Made relevant changes on-wiki for those wikis I had access to; I didn't make changes on individual users' pages. @Krinkle

Taking a look, it seems like the necessary config change was made in 2022 in MainConfigSchema.php.

How do we know the review process is complete? Is there an established benchmark for improvement, or baseline criteria that need to be met, in order to begin endpoint implementation?

In an attempt to summarize the discussion in Code Mob today, on investigation, there are several options for returning the pages/namespace(s) blocked from a user as part of the BlockInfo endpoint. Potentially, we could:

Patch initializes service and adds edits/aggregate endpoint

I added a problem constructor in AQSAssist here to create consistent error objects across the service (lowercase "get", detail array). If that's ready to merge, I'll push up the implementation in unique-devices.