libc++ futures and ports/personal libc++ use vs. what functionality is not to be used in the world/kernel: "import std" and such

This note is tied to FreeBSD keeping just one implementation of
libc++ for use for all the llvm* / clang++* . It is not intended
as a request to extend the range of libc++-tied functionality
allowed to be used in the world or kernel, at least as far as
I am concerned.

It is more focused on what will be enabled/allowed for personal
experimentation with modern C++ standard library related
functionality additions and use of cmake's 3.30's support for
such --and for ports use of such going forward. (For me it is
just the personal experimentation.)

The specific functionality I'm concered with starts with basic
C++23 "import std;" and "import std.compat;" use and grows into
more general C++20 module usage. It take more than the compiler
and linker as a build environment for such, even for just the 2
imports. As stands, from what I can tell, the FreeBSD libc++
implementation simply does not include the infrastructure that
a llvm libc++ can build that is used by cmake to have such a
build environment deal with enabling import std (and general
module) implementation.

So a question would be if FreeBSD's system libc++ would in the
future provide the infrastructure llvm has that cmake can use
to enable C++23 "import std;" and "import std.compat;" and
more.

If not, the next question might be if having something
analogous to lang/gcc* and their own libstdc++'s might be an
option, say, lang/clang++* with their own libc++'s that would
be used for that toolchain --configured to provide what cmake
makes use of. So: No longer only one implementation of libc++
around but no intent for building FreeBSD with the toolchain
and libc++ combination involved.

For reference:

https://www.kitware.com/import-std-in-cmake-3-30/

gives an idea of the current status for using cmake with the
libc++ (and MSVC) infrastructure. Questions about if
violations of the One Definition Rule (ODR) might be
possible as things are now lead to the status still be
classified as an experimental feature.

But things look to have progressed far enough to consider
what FreeBSD will do about the addition to C++ --possibly
planning to leave it simply unsupported with a libc++
via llvm involved, even for just ports/personal C++ standard
library use.

===
Mark Millard
marklmi at yahoo.com