Page to document API changes?

I am referring to api.php which is also usable via mw.Api. Is there a page for these changes already? If not, should we create one? I have already noticed a few significant differences and I think it might be helpful to users to have them conveniently documented rather then them having to figure it out by themselves. This especially so now that there won't be many (if any) legacy wikis to compare to in order to determine what might give analogous results.

Also, why are there so many duplicate categories in this Discussions and which ones are we supposed to post to?

KockaAdmiralac·12/5/2020

There is a section on the UCP JavaScript changes page for those, but I haven't got to documenting a lot of changes I've been encountering (and my adminship expired there now, but I guess I could ask Rappy for a re-promotion if there is a need). Which changes would you like documented?

The duplicate categories are because the Discussions migration duplicated our Forum boards as Discussions categories. Merging them would require me to temporarily disable our logger on the Dev Wiki Discord server which is why I didn't get to that yet.

Andrewds1021·12/5/2020

Ah. I see. Thanks for the info. Regarding the JS/CSS change pages on UCP Wiki, perhaps it would be best to move them to here? Staff told me they will be deleting UCP Wiki once they get global JS working from CC again.

As for the changes I have noticed so far:

At least when using "action=query", results are in "data.query.key" instead of just in "data.key".
The names of some of the parameters have changed. For example, "usids" is now "ususerids" for "list=users". There are also some that still work but are depreciated such as "disablepp" which is now "disablelimitreport" for "action=parse".
New parameters that are pseudo-required. For example, "contentmodel" for "action=parse" and "rvslot" for "prop=revisions". Also, the whole concept of slots.
Removed endpoints such as "list=groupmembers" and new/replacements such as "list=allusers&augroup=group".
I see you have something related to this but also "data[query-continue]" being changed to "data.continue".

Andrewds1021·1/2/2021

You can choose to read this or not. It not, then it will still serve as a record for my own purposes. Here are some things I have figured out about ResourceLoader and JS that are not on the UCP changes page. Although I suppose you might know them already.

Any user subpage ending in ".js" is recognized as a personal JS page and is assigned the appropriate content model, protections, etc.
Testing mode is now invoked by prepending "test:" to the script identifier rather than appending some timestamp as a query parameter. This appears to have the effect of allowing test mode for some but not all scripts when processing a minified request. This cannot be used on an interwiki import. It must be used when importing personal JS.
Interwiki imports - I am not sure what is going on here. It seems like it changed while I was writing this. At first, it seemed that "u:" had taken over the role of "external:" in using database names with no substitute for the legacy "u:" (using interwiki prefixes and subdomains). However, just now, "u:" seems to behave like the old "u:" even though it wasn't just an hour ago. The odd thing is that the current behavior seems to not work for all source wikis which is odd. Source wikis for which the old "u:" doesn't work also seem to not with with the new "u:" either and earlier testing indicates it shouldn't be a UCP v. legacy issue.
I am not sure how it is checking but all potentially valid identifiers are assigned the "ready" status even if the script (or a non-test version) doesn't exist. On the flip side, all non-valid identifiers are automatically marked as missing and not imported. This differs from legacy which appears to try to parse the JS to determine if the script is valid. For UCP, it appears that the only valid pages are ones in the MediaWiki and User subpage namespaces that end in ".js".

What do you think?