doctest however gets confused in such settings. E.g. I installed doctest for 9.2.5:

$ cabal install -w ghc-9.2.5 doctest --program-suffix=-9.2.5
...
$ doctest-9.2.5 --version
doctest version 0.20.1
using version 9.2.5 of the GHC API
using /usr/local/bin/ghc-9.2.5

$ doctest-9.2.5 --numeric-version
9.2.5

As one can see, doctest is well aware of the GHC version it is build for. However:

$ cabal repl -w doctest-9.2.5
Error: cabal: Version mismatch between ghc and ghc-pkg:
doctest-9.2.5 is version 9.2.5 
/usr/local/bin/ghc-pkg is version 9.4.4

From what I understand, cabal gets confused here, not doctest.

I can't shake the feeling that this cabal repl -w doctest is just a hack that in some benign cases works but in general fails.

I'm not aware of any better (or even remotely robust) way to get the correct flags for a Cabal project.

AFAIK, e.g. hie-bios / hls use the same approach to get the correct flags for a source file + other tools could benefit from it too. If there are limitations with cabal then I think addressing these limitations in cabal is the way forward.

Frankly, I don't know how cabal determines ghc-pkg-x.y.z from ghc-x.y.z

That's the relevant question.

Educated guess:

1. cabal looks at the canonical path of ghc (all symlinks resolved) and then uses any ghc-pkg next to that.
2. If there is no such ghc-pkg (as would be the case with doctest) then cabal falls back to whatever ghc-pkg is on the PATH.

(just an educated guess, somebody would need to confirm this by looking at the code)

A more robust way for cabal to find ghc-pkg would be to look at the output of ghc --info. ghc --info does not contain the path to ghc-pkg. However, it contain the path to unlit and ghc-pkg is in that same directory.

@andreasabel please try if --with-hc-pkg=ghc-pkg-9.2.5 can be used as a workaround.

@andreasabel haskell/cabal#8718 addresses this in Cabal; no changes to doctest required.

I revived @sol's PR at haskell/cabal#10057.

@sol does hie-bios/hls uses the same ghc key in their augmented ghc --info? Because I wonder if an alternative ghc:path or path:ghc would allow more flexibility if adapted to other tools/values.

I revived @sol's PR at haskell/cabal#10057.

Great 👍

@sol does hie-bios/hls uses the same ghc key in their augmented ghc --info?

I'm not aware that they would do anything in that regard right now.