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 (*).
Ok, I see what you mean now. The real problem is one of modularity: you use a library which requires package P, and that requires you to add -package P to the command line for your program. You're saying it would be nicer if the library itself had some way to say that it requires package P. This isn't so good either: package P gets added to the command line behind your back, and it might cause strange problems by polluting the module namespace. Our current solution is to put the library into a package itself, and then you can express package dependencies in the package meta-data. (note that this still suffers from the module namespace pollution problem). What we plan to do, however, is for packages with hierarchical libraries to be "automatic" in the sense that you don't have to say -package P on the command line to get access to P's modules. It'll be automatically included on the import path and linked into the resulting binary if it is actually used. Hierarchical modules don't suffer from the module namespace pollution problem.
(*) 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.
language extension flags have a real effect on the source code: they essentially specify what language the source code is written in (H98, H98+FFI, H98+FFI+TH, etc.) so IMHO they really belong in the source code. Language extensions only spill over into other modules in well-defined ways: eg. you can define a MPTC in one module, and use its methods in another module, but you can't write class assertions for that class in the second module unless you turn on the appropriate extension flag. The language extension flags are really about syntax only. Cheers, Simon