Not exactly correct - pywikipediabot have not solved it at all, instead they structured their library to avoid the whole problem and to get individual properties data separately with generators, which causes a much heavier server load. You can't ask pywiki to get page properties (links, categories, etc)- in fact it doesn't even perform prop=links|categories|.... Instead it uses a much more expensive generator=pagelinks for each page you query. Those bots that want this functionality have to go low level direct api call, and handle this issue by hand.

There are 30 frameworks listed on the docs site. If even the top one ignores this fundamental issue, how many do you think implement it correctly? I just spent considerable time trying to implement a generic query-agnostic continue, and was forced to do it in a very hacky way (like detecting /g..continue/ parameter, cutting it out, removing some prop=.. and ignoring warnings server sends due to me sending unneeded parameters. Not a good generic solution)

But wouldn't we want people NOT to use API in a inefficient way, to prevent extra server load? But anyway, I agree, lets not remove abilities - lets introduce a version parameter, and do a simple approach by default.  Those who want use the old legacy, will add &legacycontirue="" parameter.

IMO, we need the version support regardless - it will allow us to restructure parameters and resulting data based on the client's version=xx request. Plus we can finally require 'agent' from all the clients (current javascript clients have no way to pass in the agent string). There was a discussion with Roan a few years ago about it, and versioning is needed in order to do most of these things. http://www.mediawiki.org/wiki/API/REST_proposal/Kickoff_meeting_notes