One of the things I like about the basis library is it's principled stance that if it doesn't require compiler support, host operating system support, is more efficiently implementable by the compiler than would be with an external library, or has clear proven utility it belongs in a separate library. This barrier for inclusion is to me at least undoubtedly good.
Personally I would split things apart further (kicking host OS support to a separate library from the basis, as I am inclined towards non-posix hosts where most of the API requiring host support isn't implementable). And kicking out any optional types/modules to separate libraries (where said library is then optional).
So while it is about as minimal a standard library as exists, (for my purposes at least) it sometimes feels like it contains too much. Given there is no language level support for things like conditional compilation of anything optional within the basis. These tend to be my gripes with the basis... not "it needs more things".
Though, also, maybe don't go too far with kicking things out into individual separate libraries. Last year I did AoC in Scheme, and there the annoyance was figuring out exactly which of the approximately nine kajillion SRFI packages I needed to import to get different bits of functionality. A smaller number of more tightly integrated libraries that are allowed to evolve over time would have been more pragmatic.