Thoughts:

1. Most of this is really easy. Like, trivial, thirty-lines-of-disposable-fire-and-forget code easy. Most.
2. The exception is the "home wiki" element; that's not really something the core tables know, and the options for getting that are...not so elegant. So, I'd ask whether there's some room for movement on that point? A bit of me thinks we don't actually need it; if they've commented on the page AND been active on that project in the last 30 days, they're probably at least marginally active there and will get the notification.

I'm getting the impression that a lot of these cards are from the same thought purpose/driven by the same pending need for a pool of feedback providers. Is that the case?

We are not here to make your life miserable, so for this feedback pages request I think home wiki is an element we can skip - although in the first query you did include "The wiki they have been most active on in that time", which is probably what we'd need and what led us into thinking that data could be retrieved (to clarify further, the home wiki request only makes sense for en.wp and mw.org, IMHO).

It did, but the structure of the query was very different; I grabbed all the users, globally, with [tag], and then found their most prominent wiki. This is grabbing all the users associated with revisions with [one of 12 different page titles] and doing that. Like I said, I can take a stab at it, but it'll take more time than predicted.

Absent the home wiki element, here's everything-but-MediaWiki (that's a different query, which I'll run now). As said in my recent email thread it feels clear that these are all very similar and overlapping requests; this means that, combined with the "anyone who is on another list" element, it's impossible to answer /any/ of them without holding all of them in my head. I'm going to operate without that restriction and just handle all the queries at once, and then product the data. So, consider this a placeholder.

I'm not worried about time if we're talking about running time, rather than "your time" (there are other queries we asked for which may be easier, and we don't need all the results today, or even all at once). The pages are 14 :p

Standard operating procedures fully apply, especially "Use Your Best Judgment". Any wiki where the person is likely to see the message is fine.

The point behind "not on any of the other lists" is that we don't want to spam people (e.g., me) multiple times. One message per human ought to be enough. You can therefore take the requests in any order you'd like, and process serially: List #1 is any one who met the criteria; List #2 is anyone who meets the criteria but wasn't on List #1; List #3 is anyone who meets the criteria and isn't on List #1 or List #2; etc.

Yes, exactly. And by the time I get to list 10 I'm checking it against nine previous lists, all of which I have to keep around ;). I'm going to process all of these requests as /one/ request and produce a single file, unless you want them to be distinguished?

I thought that there were only six requests. ;-)

Can you (easily) flag each name in the list to show which queries it matches? I'd planned to contact each group on separate days.

Then I'll run them as distinct requests, with the aforementioned
increasingly-complex-arithmetic-series-of-filters.

Hum; I thought I'd done this one. The blocker was, iirc, the MW and legacy DE pages. How vital are those?

Which ones are the "legacy DE" pages? I'm willing to restrict the list to
Wikipdias only, in case that is a useful answer.

https://de.wikipedia.org/wiki/Wikipedia:Technik/Text/Edit/VisualEditor/Beta2013-07 - I've actually already got the data for all the WD-linked entries.

In an ideal world, we would have both mw and that old de.wp page. Separate
lists are fine. But if it's hugely difficult to get the data for those two
pages, then we can probably live without it.

It's not particularly difficult, just distinct from the other sets; working on now :).

I'll take the mediawiki page out of this, due to its complexity.

update