For original questions:

1. I believe [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 and P2412.

Thanks,
F.v.S.

From: Std-Proposals <std-proposals-bounces@lists.isocpp.org> on behalf of Marcin Jaczewski via Std-Proposals <std-proposals@lists.isocpp.org>
Sent: Sunday, June 30, 2024 20:28
To: std-proposals <std-proposals@lists.isocpp.org>
Cc: Marcin Jaczewski <marcinjaczewski86@gmail.com>
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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals