I agree on that point, but think we could also eventually look at 
expanding the API to filter on start/end dates as well and providing 
optimized queries for this in the backends that support it - instead 
of fetching all tasks and filtering in-memory.

There already is a login task to delete old, complete tasks. I think 
this should suffice to clean up large task lists.

[...]
A corresponding tag could be used for this but getTasks() would have 
to pass on the parameter to the backend for query.

This concerns Nag and especially its Nag_Api.

Retrieving tasks via getTasks() involves fetching all to-dos of a 
tasklist from the backend and sieving through the results. The only 
parameter for effectively restricting the search is the completed 
flag. There is no support for $start and $end parameters. Over the 
years a user's to-do list may accumulate a large number (thousands) of 
entries so that fetching to-dos from the backend will be an 
unnecessarily expensive operation. This may be relevant for displaying 
a user's "current status" that includes uncompleted to-dos as well as 
completed to-dos from the past week or so.

As retrieving a to-do may involve calculating recurrences, a simple 
parametrisation of the backend driver for $start and $end dates may 
not suffice. I suggest using an archive() function that marks a to-do 
as historic if it is marked as completed and there are no more 
recurrences in the future. This way all to-dos are kept in the 
tasklist and synchronising is not affected.

The archive() function could be called automatically on any change 
operation to a to-do, with a selectable threshold of age (e.g. all 
to-dos with a due-date in the past and a completed-date more than 4 
weeks ago is marked as historical).

getTasks() should support a corresponding parameter indicating if a 
search is to be made on live or archived to-dos.