It seems to me that you're removing the ability
for the client to
optimize the queries issued (besides forgoing the use of generators
entirely and having to make 10× as many queries using titles= or
pageids=) for no proposed benefit.
not 10x queries --- one additional query per 5000+ requests, for an
extremely edge case scenario you have given.
your example - run allpages generator with the gaplimit=1 -- and for each
page get a list of revisions. That means - you do at least one API request
per page. With the change -- you will need just one extra query per 5000+
requests to get the list first. A tiny load increase, for a very rare case.
I tried to come up with more use cases, but nothing came to mind. Feel free
to suggest other use cases.
On the other hand, the proposed benefit is huge for the vast majority of
the API users.
One simple "no-brainer" way to continue a query once it's issued, without
any complex code by any api client frameworks. Right now client framework
must understand what is being queried, what params should be set and
removed to exhaust all properties, what to add later. And *every* framework
must handle this, without any major benefit, but with additional chance of
doing it either in inefficient or possibly buggy way. My previous email
listed all the complex steps needed frameworks have to do.
Besides, if we introduce versions (which we definetly should, as it gives
us a way to move forward, optimize and rework the api structure), we can
always keep the old way for the compatibility sake. I think versions is a
better overall way to move forward and to give warnings about incompatible
changes than adding extra URL parameters.