By 'stdlib' do you mean all of the packages in micropython-lib? If so, then micropython-lib-all would be a fairly obvious way to install all of micropython-lib, and there would be little reason to worry that anyone will come up with a 'lib-all.py' module.

OTOH, if stdlib is a subset of micropython-lib, then it would be easy to imagine other subsets being defined. Maybe 'group'? Then we could define micropython-group-stdlib along with any other groups we want to define.

There may be a better name than 'group', but it is the first thing that came to my mind.

By 'stdlib' do you mean all of the packages in micropython-lib?

No, because micropython-lib contains extra modules beyond Python standard library, such wouldn't be included. An example is recently added "xmltok" module. And "uasyncio" is a grey area, because it's not 100% compatible, and yet directly corresponds to similar module in CPython.

(And the above is just my current idea how to do it, if for example a lot of software will depend on xmltok and it will be a chore for users to install separately, it can be included too).

If so, then micropython-lib-all would be a fairly obvious way to install all of micropython-lib

So, the focus is really on "stdlib", not on "micropython-lib", the latter being just a name of project/repository. The idea is to give users something as close as possible to CPython environment, as easily as possible (and nevermind that it's still not exactly CPython env, the subset is already pretty big and useful).

OTOH, if stdlib is a subset of micropython-lib, then it would be easy to imagine other subsets being defined. Maybe 'group'?

I personally don't imagine any other cross-package subsets like that defined. micropython-lib is 95% stdlib, and the rest is just few by-exception modules which provide very stdlib-like functionality, so there were let in, to not create separate repo for each. Those will remain few and exceptions.

Well, actually, there're such groups can be imagined. It's a meta-package for installing modules which form complete package. For example, there's currently micropython-collections.defaultdict, micropython-collections.deque, etc. There's also micropython-collections which makes individual submodules to be accessible under "collections" package. There could be micropython-collections-all which would just install complete "collections" package, with all submodules. But well, I'd say that micropython-collections-all is just right name for it. (And then if maintaining consistency, top-level "all" package should be named micropython-stdlib-all. Or maybe micropython-all after all? ;-))

micropython-all is the less confusing name or perhaps micropython-meta-stdlib? Since there could be other packages in the future with mircopython-meta-* prefix. It is easier to filter through packages this way, instead of sticking meta to the end of the package name.

Over the last 8+ years there has been no motion on a metapackage for micropython-lib. Proposing to close this issue as not-planned.

We do now have the concept of a package "bundle", and there's bundle-networking as the first one of these. So, if this issue were to be revisited, we would use a name like bundle-stdlib.