Stack and other tools are attempting to make the user-experience of developing multiple packages simultaneously better. Thus, if you have source packages p, q and r (which all depend on them), stack build builds all of them. They are quite interested in support stack ghci but there are problems: https://github.com/commercialhaskell/stack/issues/665

edit: These are Edward's original technical notes. The new plan is in https://gitlab.haskell.org/ghc/ghc/-/wikis/Multi-Session-GHC-API . Both his 1) and 2) are solved dispensing with a notion of a single "home package", and instead having multiple, with their own flags (including src dirs) etc.

The essence of the problem is twofold:

1. If you ask GHCi to interpret modules from multiple packages (e.g. by having multiple source directories), GHCi currently only knows how to put all of them into the same home package. This will fail if two packages have a module with the same name; also, modules in the other packages will always see modules (even if they're supposed to be hidden).
2. A GHCi session only has one global set of dynamic flags, but each package may be compiled with its own set of DynFlags (e.g. package global LANGUAGE pragmas). This means the "default DynFlags" needs to be varied between packages.

It's not too obvious to me how to fix (1) (at least, you'd have to make the HPT support sets of HomeModInfos from multiple packages), but (2) seems tractable: since we already track DynFlags on a per-module basis, we just have to arrange for a "package" level DynFlag to be applied to the correct ModSummarys.

Similar functionality would be useful for Backpack.