You have to understand that the above command does two things: it compiles Y.hs to Y.o, and then it links Y.o with libraries to form a binary. In the first stage, all exposed packages are available (because you didn't say -hide-all-packages), so Data.Time from package time is in scope and you can successfully import it. At link time, all you have to do is make sure the required packages are linked in, and you did that by explicitly linking something (P) that depends on package time, so package time was linked in too.
I don't think there's anything really "wrong" here, that's just the way it works when you don't use --make.
ah, thanks! somehow, i had been living under the misconception that, to get at any non-base package's modules, i would have to use either --make or -package. as if -hide-all-packages -package base was the default, in other words. instead, the distinction is exposed vs hidden, which makes sense. (*) which means that my test setup was useless, other than supporting link-time dependency recording. package dependencies are another matter, since for building packages -hide-all-packages is the default, and my setup did not, after all, re-export modules as intended. one might still re-export modules under their original names, by using two packages. for the time example: a package P can depend on base and time, importing Data.Time, exposing P.Data.Time; then, a package Q can depend on base and P, importing P.Data.Time, exposing Data.Time. with this alternate setup, ghc -hide-all-packages -package base -package Q Y.hs succeeds (this time hopefully for the right reasons?-). if i recall correctly, the grafting/mounting/package-qualifier proposals were attempting to formalise this linking of package modules into a module hierarchy, in various ways. perhaps providing package qualifiers (with a way to disambiguate between package and module names) could be reconsidered, given that mounting of package modules in the hierarchy may then be achieved via intermediate packages like Q above? (*) still, i find this two-things separation confusing, because the compiler only "half-knows" about things (being able to compile without complaint, then fail in linking with confusing errors), and because -package serves two separate purposes (exposing packages, and enabling linking). i'd rather keep the illusion that link objects are an internal representation of source modules, and either both compile and link succeed, or both fail, with a source-level error message. claus