This seems like a strange special case, but as stated it would be possible with caveats. I have to reject the direct approach unless the DBAs tell me it's ok if the query potentially has to touch millions of rows in some cases (i.e. bugs like T97797).

If the caveats are not acceptable and you can't propose a specific alternative plan, we may as well decline this task.

Add a param to specify the other users who must have edited the page to include in the query.

This is unclear. If you want contributions of Alice and specify Bob, Carol, and Dave as the "other users", which case are you intending?

• Alice's contributions to pages that all of Bob, Carol, and Dave also edited.
• Alice's contributions to pages that any one of Bob, Carol, or Dave also edited.
• When you said "other users", you actually meant "one other user".

One possible approach would be:

1. Fetch the uclimit contributions for the named users, as the module does already.
2. Extract the set of pages in those contributions.
3. Fetch the set of those pages also edited by the specified users (a SELECT on revision targeting the page_user_timestamp index, or in the future the page_actor_timestamp index)
4. Filter the contributions from step 1 (in PHP code) to only return the pages in set 3.

Caveat: This will likely return fewer than uclimit results, possibly zero. The client will have to continue the query to get a "full" set of results (whatever it considers a "full" set to be).
Caveat: Until T167246 is complete, the "other users" must be registered accounts. The named users (for whom the contributions are being fetched) can include IPs.

A second, more complex possible approach would require a new index to the revision table on (rev_user, rev_page), or in the future (rev_actor, rev_page), or a new table that contains just the distinct rev_page and rev_user/rev_actor pairs.

1. Fetch the next 5000 pages that the named users contributed to (a SELECT on revision targeting the new index, or on the new table).
2. Fetch the set of those 5000 pages also edited by the specified users (a SELECT on revision targeting the page_user_timestamp (or in the future the page_actor_timestamp) index, or a SELECT on the new table)
3. Fetch up to uclimit contributions for the named user to the set of pages in step 2 (targeting the page_user_timestamp index, or in the future the page_actor_timestamp index).

Caveat: The results will be sorted by user, then page_id, then by timestamp. The results are normally ordered by user and timestamp. Or, if T180153 happens, the results would be sorted by page_id then timestamp.
Caveat: Until T167246 is complete, the named users and the "other users" must all be registered accounts.
Caveat: You might still get fewer than uclimit results, possibly zero, although the risk is less than with the other plan.
Caveat: This probably can't work with ucuserprefix once T167246 is complete.