This is an incompatible api change and breaks any code that was relying on getting all such items in this way.

Indeed and as such was announced in the release notes: https://docs.pagure.org/pagure/changelog.html#id2 (4th point from the top).

side note: is pagination stable? If I query page after page, and something changes in the middle, could I miss an item (or see a duplicate) due to alignment shifts?

Good point, I suspect not :(

Why was an incompatible change required? Was the default creating memory load issues?

Is there any way a call can explicitly ask for all the results?

Why was an incompatible change required? Was the default creating memory load issues?

One of the API endpoint was returning almost the entire database making it a very easy DDoS attack point (query a few time that endpoint and you were bringing the server down on very large deployment).

Is there any way a call can explicitly ask for all the results?

Nope, you can ask up to 100 results per page, but you have to go through each page

Is there a recommended way for iterating over the pages in general? I've sort of hacked up a workaround in my code for now. The challenges I'm seeing are:

1. (at least according to the api docs), the pagination data returned appears to be a little inconsistent. pagination field vs specific pagination_* fields (e.g. pagination_issues_assigned), or other variations (like repo_pagination).
2. sometimes the parameters themselves vary (repopage, forkpage)
3. difficulty merging the results in general. the field containing the primary result varies, or is sometimes split (e.g. issues_assigned, issues_created)
4. general slowness. I guess each call is a duplicate query, right?
5. (potentially) the pagination stability issue

(trying to avoid rewriting the same code for every call)