Matthew, I realize this to be a controversial issue, but what you're suggesting is effectively an attempt at cutting this cabal V2 feature off at the knees ("If Cabal won't change its default let's cripple this feature on GHC's side by rendering it pointless to use in cabal"). If ghc environment aren't read anymore by default they fail to have the purpose they were invented for in the first place! At the risk of repeating things I've tried to explain already in the GitHub issue let me motivate (again) why we have these env files: We want to be able to provide a stateful interface providing the common idiom users from non-Nix UIs are used to, and which `cabal` and `ghc` already provided in the past; e.g. ,---- | $ cabal v1-install lens lens-aeson | | $ ghc --make MyProgUsingLens.hs | [1 of 1] ... | ... | | $ ghci | GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help | Prelude> import Control.Lens | Prelude Control.Lens> `---- or similarly, when you had just `cabal v1-build` something, you'd get access to your projects dependencies which were installed into ghc's user pkg-db. This is also a workflow which has been well documented for over a decade in Haskell's literature and instructions *and* this is the same idiom as used by many popular package managers out there ("${pkgmgr} install somelibrary") So `cabal v1-build` made use of the user package-db facility to achieve this; but now with `cabal v2-build` the goal was to improve this workflow, but the user pkg-db facility wasn't a good fit anymore for the nix-style pkg store cache which can easily have dozens instances for the same lens-4.17 pkg-id cached (I just checked, I currently have 9 instances of `lens-4.17` cached in my GHC 8.4.4 pkg store). So ghc environment files were born as a clever means to provide a thinned slice/view into the nix-style pkg store. And with these we can provide those workflows *without* the needed to pass extra flags or having to prefix each `ghc` invocation with `cabal repl`/`cabal exec`: ,---- | $ cabal v2-install --lib lens lens-aeson | | $ ghc --make MyProgUsingLens.hs | Loaded package environment from /home/hvr/.ghc/x86_64-linux-8.4.4/environments/default | [1 of 1] ... | ... | | $ ghci | GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help | Loaded package environment from /home/hvr/.ghc/x86_64-linux-8.4.4/environments/default | Prelude> import Control.Lens | Prelude Control.Lens> `---- (and respectively for the `cabal v2-build` workflow) However, if we now had to explicitly pass a flag to ghc in order to have it pick up ghc env files, this would severly break this workflow everytime you forget about it, and it would certainly cause a lot of confusion (of e.g. users following instructions such as `cabal install lens` and then being confused that GHCi doesn't pick it up) and therefore a worse user experience for cabal users. Even more confusing is that GHCs GHC 8.0, GHC 8.2, GHC 8.4, and GHC 8.6 have been picking up ghc env files by default (and finally we've reached the point where the pkg-env-file-agnostic GHC versions are old enough to have moved outside the traditional 3-5 major ghc release support-windows!), and now you'd have to remember which GHC versions don't do this anymore and instead require passing an additional flag. This would IMO translate to a terrible user experience. And also tooling would still need to have the logic to "isolate themselves" for those versions of GHC that picked up env files by default unless they dropped support for older versions. Also, how much tooling is there even that needs to be aware of this and how did it cope with GHC's user pkg db which can easily screw up things as well by providing a weird enough pkg-db env! And why is it considered such a big burden for tooling to invoke GHC in a robust enough way to not be confused by the user's configuration? IMO, shifting the cost of passing an extra flag to a tool which doesn't feel any pain is the better tradeoff than to inconvience all cabal users to have rememeber to pass an additional flag for what is designed to be the default UI/workflow idiom of cabal. And if we're talking of e.g. Cabal/NixOs users, the Nix environment which already controls environment vars can easily override GHC's or cabal's defaults to tailor them more towards Nix's specific assumptions/requirements. Long story short, I'm -1 on changing GHC's default as the resulting downsides clearly outweight IMO.