right, there is a tension between having just independent APIs and
having also independent implementations. My main goal is to allow
packages to specify their imports more precisely, to require less
changes as not-so-common stuff in base evolves and to make it easier for
alternative compiler/targets to implement parts of base; this would just
require providing better grouped APIs.

But if we want that while retaining the freedom to have an entangled
implementation, we are back at the "large base + specific re-exporting
packages" approach, which wasn’t particularly well received here.

I don't know about entangled implementations. But I'd like to have a base package (e.g. your base-pure) that has a consistent set of basic data types e.g. Int, Word, Float, Double, Char, String, ByteString, Text, [a], Maybe, Either, and so forth. These are logically at the same layer. I think splitting them according to how they happen to be implemented at the moment is a misstake. It would give us a illogical and unstable layering in the long run.