I'm on Debian 12 and I just started using Haskell's ghcup tools, leaving the stack tools behind, as advised these days. ghcup puts executables for Haskell such as ghc, ghci (REPL), cabal, etc. in its ~/.ghcup/bin directory. Next, to stop using the stack tools that have executables in /usr/bin/ you must change your PATH to go to ~/.ghcup/bin first. But when I try a Babel code block, ob-haskell seems to have the /usr/bin versions hardwired somewhere and calls up the old ghci REPL. Searching through Emacs Customize Haskell was confusing and my init only had one relevant entry anyway, which didn't help when I changed it.
In the /usr/bin directory the Haskell execs are linked to just one specific version. In my case /usr/bin contained symbolic links ghc -> ghc-9.0.2 and ghci -> ghci-9.0.2. This is not great, since Haskell in the wild is project-based, i.e., differing versions of the ghc compiler can be used in different projects, as well as wildly diverging libraries and packages per project. Obviously Babel can't easily take advantage of this, but Haskell does allow "system-wide" library installs.
My solution was to simply delete the symlinks in /usr/bin and create new ones to the ghcup tools, e.g., ghc -> ~/.ghcup/bin/ghc etc. So now it works properly and calls up the new ghcup ghci when I do a Haskell Babel block, but this is a kludge. No elisp master, I can't find where this /usr/bin address is hardwired. If you've gotten this far you probably know more about the Haskell Babel situation than you ever wanted to, but maybe you can sniff out where this hardwire is happening.
-- ⨽
Lawrence Bottorff
Grand Marais, MN, USA