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.