FreeBSD libc++ , ports, and import std or import std.compat : what if potential ports start using them over time?

This is more of an early-warning note than an immediate-action-
required note.

import std or import std.compat are reported to have the property of
cutting build times vs. the historical use of headers. This could
lead potential ports to needing to port things that are based on
import std or import std.compat upstream, for example.

FreeBSD has the property that the only implementation of (modern,
clang based) libc++ is the one provided by the system. Having
the ports environment have its devel/llvm* contexts use their own
libc++ that might not match or be compatibile with the system
libc++ is not provided for currently, as I understand.

But, as far as I can tell, it looks unlikely that the system libc++
would be configured to allow import std or import std.compat :
There looks to be extensive compiler options matching requirements
for how the supplied std and std.compat were set up before they
can be used. Building FreeBSD itself may have no intended use of
the likes of import std or import std.compat .

This leads me to wonder if FreeBSD will enable alternate libc++
usage for ports at some point in order to allow ports to use import
std and/or import std.compat . Might that need, say, a lang/clang++*
separate from the devel/llvm* ? Likely not intended for building
FreeBSD itself?

A problem here is avoiding he need for any process to have multiple
libc++ implementations. This might be messy enough to block use of
import std or import std.compat in ports fairly generally, needing a
from scratch bulk -a run that is overall based on a specific
alternate libc++ for example. (May be only those folks building
there own packages/ports get to do such?)

Has anyone been looking into the implications of attempting import
std and/or import std.compat use for c++ use in a FreeBSD context
(with the c++ library, not just the language)?

===
Mark Millard
marklmi at yahoo.com