libc++ version is currently tied to a specific FreeBSD release. If third-party software depends on bleeding edge C++ features it may fail to build. And pulling newer version from ports is risky due to ABI mismatch. To avoid Perl-style blunder let's promote the port version instead.
For example, FreeBSD 10.x cannot benefit from complete C++14 support.
Another issue is on libc++-enabled systems libstdc++ from ports cannot be used. theraven@ proposed to link libstdc++ against libcxxrt (like in gcc42 case) but that often requires bleeding edge version of it. 11.0+ release model should accelerate updates adoption but relying on libsupc++ compatibility still leaves some gaps as FreeBSD tries to maintain ABI instead of leaving it to upstream.
I think that a better solution to this would be more frequent upstream imports into base (which should become a lot easier to push to users once we have packaged base). Making libc++ a private library would mean that it would not be possible for users to compile C++ programs without installing a port, which would be a major regression. If we did that, then there's little point having a C++ compiler in the base system at all.
Libc++ aims to be backwards binary compatible, and so there shouldn't be any POLA violations from installing a newer one.
Can we create/revive the libc++ port? We can still have the base version, but we can also allow people to install the port version, and let other ports depend on it. When compiling dependent ports, compiler flags can be set to use the header file from the port, and link with the libc++ library from the port. During runtime, the port version can use libmap.conf to redirect every program to use the library from the port.
(In reply to Henry Hu from comment #3)
That should be fine, as long as there aren't any ABI compatibility problems between the different versions. The problem comes when two libraries used by the same program both use libc++ and end up with different versions. As long as it's fine for both to use the newer one (which it should be with libc++) then that's fine.
We will likely to a libc++ ABI break in 12.0, but that's probably not a good idea for the port running on 11.