Putting different sections of the standard library in different
modules has little *practical* benefit in terms of compile times or
standard library module distribution (that I know of). As such, if you
want the modular standard library to have different sections, there
needs to be some other practical benefit to having those sections.

What you've outlined here feels very much like a personal thing. You
want to prevent your coders from using certain parts of the standard
library, and those parts just so happened to conveniently be cordoned
off into certain specific headers. So you banned those headers from
being included.

And that's fine. But that was never intended to be a promise from the
standard to ensure that these sections would be perpetually cordoned
off to their own headers. And indeed, different people have
per-project needs for what parts of the standard library should and
should not be available. There are probably some algorithms in
<algorithm> that some projects would like to ensure never get used.
But they couldn't do it on a per-header basis, so they had to employ
other means.

You managed to get lucky; the things you wanted to cull happened to
neatly line up with headers. But that shouldn't be taken as a
statement that things will continue that way in perpetuity.

That's not to say that the single unified `import std` module is
necessarily the best way to go. But I feel like if the committee wants
to break the standard library into chunks, this particular reasoning
(ie: I want to stop users from using standard library feature X) isn't
the best reasoning for any particular chunk assignment.