(1) feels like an implementation detail of GHCJS that has been promoted into something everyone will have to deal with. I would like us to give this design some more thought (preferably with input from Duncan) before we merge these changes.
It's not so much an implementation detail of GHCJS itself, but more a side effect of many people using impl(ghc) flags in their packages to check whether the compiler supports some particular feature. We could leave it out, but then many packages would have to be updated to duplicate the impl check (or replace it) The effect on the Cabal lib itself is minor, and the impl(ghcjs) flag would be false for anyone not using ghcjs.
(2) is fine.
I haven't looked in detail at (3), but improving code reuse seems reasonable. Perhaps we should move the shared functions to D.S.GHC.Base or something to not complicate the API offered by D.S.GHC.
I'm testing a new version that requires no changes to the code in the GHC module, other than some exports, so don't look at this in detail yet (like i said yesterday, it's ready today, which is, before i go to bed) luite