Again, your trying to make the server "smarter" for one case makes it dumber in other cases. What about gaplimit=max&pllimit=max&pllinks=Foo? Or what if you're using generator=categorymembers&gcmtitle=Category:Pages_with_no_links (perhaps to check if any have links so they can be removed from the category) instead of generator=allpages?
First - I agreed we can keep both. With versions it won't break anything.
If the user wants to continue using this, they can specify legacycontinue parameter in addition to version. Its a win win - the simpler users will use the more direct approach without much thought, the more advanced users, in an unlikely case they find use for it - will use the legacycontinue. The important thing is that default is easy, not hard.
Second: Please look closely again at my description of different use cases and their server load. Your examples are absolutely no different -- It does not matter if the properties on the page have many links or few links - the case of pltitles=Foo or no-link categories - you still will want to look at either 80% of the page titles in one block - in which case you execute all the subquery continues, or you need just one or two page titles per block, in which case you would have saved server resources a lot by filtering them first and than asking the server with a pageid list. When I designed generator, I assumed that ALL needed properties will be returned at once, without any continuations. With the addition of the prop continue, this model breaks down and becomes very inefficient.
Mine does, although it's probably not listed there. I haven't tried
anyone else's.
Unfortunately most framework developers do not have your expertise. I wish
they did, but they don't.
But "legacycontinue" isn't a version parameter, it's a feature selection parameter.
Its an additional parameter required for legacy support in the new API
version. See above.