I think there is an argument to be made for "something super basic in `std/`
that could maybe be a B-tree" and _something else_ with a lot of knobs/levers
when people know they want a hash table and want to be able to tune it. In
fact, that might even be what @Araq has a draft of.
I am also fine with `lptabz` or something like it moving into `std/` and in
general a "big std/". There are many other features of `lptabz` that might be
popular. While I understand that Nim-core is overwhelmed and there are over a
half dozen package managers, brand new users are probably better served not
having to learn anything beyond "import std/xyz" and that aspect of UX also
matters.
People praise Go's stdlib and used to praise Python's (and now instead struggle
with requirements.txt and Docker and ...). Linus long ago lost track of all
things going on in the Linux kernel and instead has a "trusted lieutenant"
model. At least since C++ STL & Java, I have thought "stdlibs sell prog.langs".
Maybe things have shifted to "package managers sell prog.langs" { and that
shift started with CTAN/CPAN (around the same time as STL/Java)! Hah! -- In
human affairs, "all of the above" is often overlooked, yet more accurate than
any one thing }.
Anyway, there are no absolute answers to any of this -- delegation saves so
much/allows scaling but trust sure is tricky! It's all an infectious cluster of
[Wicked Problems](https://en.wikipedia.org/wiki/Wicked_problem) sometimes
called ["coordination games"](https://en.wikipedia.org/wiki/Coordination_game)
which may be simply insoluble. In terms of your expectations, I think it goes
against current thinking of instead trimming the stdlib as much as possible.
