Essentially, compile strongly-connected sets of modules like single modules are compiled (they have to have the same default and monomorphism-restriction, so it is like compiling one module, after the module/import fixpoint and name resolution are done).

This can increase the amount of recompilation necessary compared to using .hs-boot files, so it is probably desirable to still allow those. Of course, manually keeping .hs-boot files and #SOURCE# pragmas around (and synchronized with the real code) is a nuisance (though informative if one cares about minimizing the amount of recursion). I suspect that there can be situations where one level of export-subsets via .hs-boot files is not sufficient... (which would be one reason it wouldn't be easy to "just" treat a subset of each .hs file as its .hs-boot).

When not using --make mode, ghc would have to find the minimal module cycles somehow, and put just one ".hi-boots" or ".his", and .o I think, file somewhere (next to an arbitrary one of the modules I guess) in order that the compilation isn't repeated pointlessly for each module. And deal with which compiler flags are used. Maybe better not to allow it without --make.

In --make mode, such hackery should not be needed. This might also help deal with (work around?) such existing bugs with recursive modules and --make: #930 (closed) , #1072 (closed) , #1133 (closed) . The modules having different OPTIONS_GHC or LANGUAGE pragmas might still be tricky or impossible to accept, depending which ones they are and how much implementation effort it's worth investing in allowing that. (Although, class instances being overlappable might be advantageous to have implemented a per-class not per-module specification anyway, for example, so pragmas that affect less than the whole module could be added more easily.)