For original questions:

1. I believe [std.modules]/2<https://eel.is/c++draft/std.modules#2> already indicates that std and std.compat modules are sliced to the freestanding subset in a freestanding implementation. In such a freestanding environment, you won't get std::vector when using standard library modules. There's no issue I see with freestanding implementations.

2. Currently there's no active paper for finer grained standard library modules. Perhaps you can write a paper superseding P0581<https://wg21.link/p0581> and P2412<https://wg21.link/p2412>.

Thanks,
F.v.S.

________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Marcin Jaczewski via Std-Proposals <std-proposals_at_[hidden]>
Sent: Sunday, June 30, 2024 20:28
To: std-proposals <std-proposals_at_[hidden]>
Cc: Marcin Jaczewski <marcinjaczewski86_at_[hidden]>
Subject: [std-proposals] Freestanding std modules

On GCC mailing list I notice email:
https://gcc.gnu.org/pipermail/gcc/2024-June/244252.html
Aside of misguided author (profanities & sending it to gcc instead of here)
some of his concerns could be valid.

Example: there is a freestanding version of the standard library module?
Or how to reduce blot that `import std;` can cause even if I only
use part of it like `std::vector` or `std::unique_ptr` but
I do not plan touching `std::regexp` or io.

Maybe something like `import std.core;` (like MSVC did) or
use import headers like `import <iostream>;`?

Or is this simply a QoI issue and the committee does not need to consider
how big is binary after `import std;`?

--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals