I'd argue that -package is a global option and should stay that way. The only reason you might want to disable -package for certain modules and not others is if you want to do some tricks with module shadowing - and this definitely isn't supported in GHC. You should pass the same -package to every compilation.

Funny, I wasn't actually thinking of hiding -package (effectively giving it a scope) when I wrote that. AFAIC, it would be fine for GHC to collect all the -package options from the source files it wants to compile and then use the same superset of package options for all of them (*). But it would be helpful if each source collection could include the information ghc needs to compile it. So if I have sources A that happen to need -package HOpenGL and sources B that happen to need -package lang, etc., I could simply document those dependencies in the sources in a way ghc would understand. And if I have a project C using both A and B, and I need to modify anything in A or B, I could still simply let "ghc --make C" figure out what to do by just telling it where to find A and B. Whereas currently, I have to go back and figure out what packages A or B need to be compiled with.. (or not use ghc --make, before anyone else suggests that;-).

I think -i is a global option in the same sense as -package, though. The library options -l and -L don't really matter, since they're only used at link time and you wouldn't want to put them in OPTIONS anyhow.

Same here, for non-package dependencies. Claus (*) I didn't want to have global supersets of options for language extension flags, but those seem to be dynamic anyway, and often, their effects spill over to anything wanting to use the modules that use language extensions.