Maybe the proper is to reverse the whole approach: Leave base as it is,
and then build re-exporting smaller packages (e.g. a base-pure) on top
of it. The advantage is:
* No need to rewrite the tightly intertwined base.
* Libraries still have the option to have tighter dependencies.
* Base can evolve with lots of breaking changes, as long as they
do not affect the API by the smaller packages.
* Development of this collection can happen outside the GHC tree.
* Alternative implementations for (some of) these packages can be
created, if the reason why they could not be moved out of base
is one of implementation, not of API

How does that sound?

I'm not in favor of this approach as it precludes pushing any data types down the stack. In particular, we want text and bytestring to be below the I/O layer, so we can defined Handles that work with those in base itself.