>> Even if knowing the module(s) related to the issue is useful, there are a
>> number of problems that should be considered:
>> * there are hundreds of modules;
> How many exactly? I doubt there is more than hundred.

More than two hundreds.

>> * several modules can be related to the issue;
> Make them tags.

What are tags?

>> * the list of modules must be updated when modules are added/removed/renamed;
> Store module mapping in repository and throw warning during build
> stage when files added or removed.

Or maybe use the mapping in lib2to3.fixes.fix_imports (not sure the Python used for our Roundup is recent enough.)

>> * a new field adds clutter to the UI and more work for the submitters and triagers;
> Split reporting in two steps like in Gnome or Eclipse Bugzillas.

Interesting idea.

>> * searching for a specific module won't include the issues if the field is not set
>> correctly (i.e. old issues and issues that haven't be triaged), the normal search will;
> All issues should undergo triaging process. Opened old issues can be
> retriaged. Closed could be left RIP. If you want to find them - use
> module name in normal search - it will still work.

“Should” is nice.  How do you propose to implement it concretely?  It could possible to add a special “untriaged” state used in queries, but I’m not sure this would help; given enough volunteers with enough free time, bug triaging happens quite effectively.  The weekly email also helps find unanswered reports.

>> Another option is looking automatically at the attached patches, figure out
>> what files they affect, and make this information available.

Sounds good.  I’m sure difflib can do that.

> But mind you that issues without patches may never get any, because module
> maintainers are unaware that there are issues for them.

There are triagers who use the experts list (in the devguide) to add maintainers to nosy.