A general comment. It would be nice if base was split into GHC and non-GHC parts. But I’m just day dreaming.
The work I’ve been doing with Simon on known-keys !15899 will make it possible to move a lot of code from ghc-internal back into base. At which point, it’ll be normal code rather than re-exports. It doesn’t solve the whole thing, but it’s a good start!
To split base up into GHC-specific and GHC-independenty parts would be entirely possible.
But it depends on someone defining an API that is implementable by several compilers (notably both micro-hs and GHC), upon which base can depend and which can be implemented by each compiler separately.
You might wonder if that is precisely ghc-internal. But that’s not the case right now: ghc-internal is precisely what it says: internal to GHC and with no aspirations to be compiler independent.
Once someone defines a compiler-independent API on which base can depend (in a compiler-independent way) then we can see if it’s best addressed by splitting base, or by re-defining ghc-internal to meet that API.
In short: we have now removed all the technical difficulties with defining base atop a compiler-independent API. What remains is the question of who will design this compiler-independent API. The way lies open!