I recently upgraded from ghc 9.2 to 9.6 (I know, I'm slow), and one of the things I was looking forward to was better recompilation avoidance, that wouldn't be fooled by spurious mtime changes that are common with with e.g. git branch switches. Unfortunately, it seems to have gotten buggy at the same time! I upgraded again to 9.12.4 and it looks like it's still buggy. Either that or I'm doing things wrong somehow. Here's a repro, it requires 3 modules: % cat >BugA.hs module BugA where x :: Int x = 13 % cat >BugB.hs module BugB where import qualified BugA f :: IO () f = print BugA.x % cat >BugC.hs module BugC where import qualified BugB bug :: IO () bug = BugB.f % ghci -fobject-code # compile so we can load .o GHCi, version 9.12.4: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/elaforge/qlib/dotfiles/.ghci Prelude> :load BugC [1 of 3] Compiling BugA ( BugA.hs, BugA.o ) [2 of 3] Compiling BugB ( BugB.hs, BugB.o ) [3 of 3] Compiling BugC ( BugC.hs, BugC.o ) Ok, three modules loaded. Leaving GHCi. % ghci Prelude> :load BugC Ok, three modules loaded. Prelude BugC> bug 13 As expected! Now go edit BugA.hs, and change 13 to say 14, and save. Now reload: Prelude BugC> :r [1 of 3] Compiling BugA ( BugA.hs, interpreted ) [Source file changed] Ok, three modules reloaded. Prelude BugC> bug 13 So that's not right! This will also cause linking errors if something was removed, though it's easier to reproduce the stale values. For my interpretation of what's going on, I believe previously it would have also reloaded BugB. While it has noticed that BugA must be reloaded (and switched to bytecode), it hasn't noticed that BugB is in the dependency path and should also be reloaded, and possibly winds up using stale values inlined into BugB.o. Is it a bug?