Regarding M. P. Jones proposal to move command-line options to the module space, I would like to reiterate something from an earlier email: What if you want to express that "overlapping instances" are fine for a certain class C but not for the rest? Recasted to the module speak of MPJ, would that require some parameterisation? I am sure this question makes sense for several extensions. (A humble solution: One could dedicate a module to the class C, and then rely on scope rules for modules regarding the propagation of the "import Extension.OverlappingInstances".) Another issue is of course that this modulish approach, which I like very much, requires sometimes that an imported extension X is *reexported* from hacker module H so that some other module A will also be compiled with the corresponding extensions enabled. Such invasive, implicit reexport is quite non-standard. In general, this raises the issue of scopes for such extensions. For some extensions, they might be *invasive* that they really require special code for all modules. For some other extension, there might be a *choice* for applying the extension to the given module or also all clients transitively or non-transitively. Aligning these options with the module system, or more precisely with the existing scope/import/export rules of the module system seems to be non-convincing to me at this stage. In fact, finding the ultimate solution would go beyond the scope of Haskell, it would be an achievement for programming languages but also software configuration in general. Regards, Ralf