I've attached a patch to parse a tasklist from the text by prefixing 
the line with a partial task list name, followed by a colon. For 
example,
I haven't run any of the unit tests, however -- if someone can point 
me to any docs on the test harness I'll give it a go.

Also if this is accepted the "Quick Add" form should be updated to 
include a description of the new feature. That would require new 
translations, unfortunately. I can contribute Spanish, at least...

It's an internal Nag method, so all usages of that method can be 
easily covered if necessary. That being said, there is no need to 
change the signature at all. Either a tasklist can be parsed from the 
text, then it's being used, otherwise it falls back to the current 
behavior.

The Nag::createTasksFromText() method takes a $tasklist argument. The 
documentation for that method states:
I'm not familiar with the usage of this method outside of the Quick 
Add list, so it may be completely safe. Perhaps the next question, 
then, is how should the API be changed to support the new feature 
while still allowing the old behaviour? To follow up, is there any 
situation in which a tasklist specified in the text should *not* 
override the $tasklist param, or vice-versa?

I'd personally tend toward adding a boolean argument indicating if the 
task list should be forced to the non-null value passed as the 
$tasklist param, or if the text can specify a task list. If someone 
more familiar with the codebase can confirm that the Quick Add form is 
the only place where this method is used, that would not be a 
necessary addition.

We already do something similar for tags in the quick add form.
I'd be for extending this to specifying the task list.
why?

I can definitely understand the desire to keep the form as simple as 
possible. However, in my organization shared task lists are used to 
manage various projects and so its important that new tasks are added 
to the correct list. In other organizations perhaps it would be as 
simple as tagging tasks appropriately.

I can see a couple of compromises:
1.  With some added text processing to Nag::createTasksFromText, users 
could set the task list per-item, eg by prefixing it with part of the 
task list name "shared: make a birthday card"
2. Add a preference for additional fields on the "Quick Add" form, 
including the task list, priority, and anything else that may seem 
relevant.

Option 1 involves possibly breaking backward compatibility and is 
therefore dangerous, although it is a nice feature IMHO. Option 2 is 
probably a better choice, since it allows a system policy to be made 
by administrators and is more straightforward to the user -- although 
it does seem to be pushing the definition of "Quick".

I can code up one of those solutions, if you'd consider accepting it. 
If not, I can totally understand your motivation.

I'm inclined to reject it, because this form should really be kept as 
simple as possible. Where should we draw the line? What if anybody 
thinks that the form is fine, but only a field to set the priority 
would be missing? Why is the tasklist different from that?

The "Quick Add" window is very useful, since many nontechnical users 
find that forms with many fields are overwhelming. In order to 
encourage these users to add tasks to the proper list, I've included a 
patch that displays a drop-down list of available task lists below the 
entry form.

A working patch is attached. I'm currently using it in production and 
would be open to any suggestions.

Thanks!