Thanks for reviewing the patch Martin.

> Why do you remove the code that loops over Modules/Setup? Maybe is it redundant with the other code for removing the already-built-in modules?

Yes because this is redundant, maybe not the case when this was written 15 years ago.


> The logic matching MODOBJS doesn’t look super robust.

Agreed on both points.


> if you added Modules/Setup.config to the list of Setup files to process, would that eliminate the need to look at both MODOBJS and sys.builtin_module_names?

The processing of the Setup files done by setup.py is not robust either. It does not handle the lines of the form '<name> = <value>'. The syntax described in Setup.dist allows for:
    mod_form1 mod_form2 _mod_source.c
where both the 'mod_form1' and 'mod_form2' modules depend on the same source file and one would like to build them statically. makesetup handles that case while setup.py does not.
There is no guarantee that a change in the makesetup machinery would be systematically reflected in a change to setup.py. And indeed this is the case now - as you point it out - setup.py is currently missing the parsing of Setup.config.

Here is a new patch that uses the result of the parsing done by makesetup in setup.py.