So you are conflating tons of things here and none of it really makes sense. The reason why compiling for macOS tends to claim stuff like how C++ features are t

So you are conflating tons of things here and none of it really makes sense. The reason why compiling for macOS tends to claim stuff like how C++ features are tied to operating system targets is because Apple doesn't really understand how to do toolchain architecture well and so have managed to do this awkward thing where the operating system--from their perspective--is this massive monolithic brick that contains a ton of functionality that is classically introduced by the toolchain, which I admit has some advantages but generally feels ill-intentioned. The result of this is that Apple really assumes you are going to use the copy of libc++ that ships on the system, and it might be missing exported systems that are assumed by the library. But this isn't related to the toolchain you are using. I do remember some weird corner case with std::optional and I think it might have been that Apple forgot to mark something correctly as unsupported in a previous toolchain build? The newer compiler is thereby actually giving you the more correct understanding of what can actually be presumed to work on older systems. But like, the core issue here is that you really shouldn't use Apple's stupid toolchain setup, nor do you have to: just embed your own copy of libc++ and call it a day. I routinely use the latest versions of Xcode's copy of clang (though I prefer to compile for macOS now using the copy of clang that comes with the Android NDK for various reasons: I recommend avoiding Xcode except to get their system headers) to target ancient systems with modern C++ features as I'm not relying on the system copy of libc++ to even exist or work (10.7's doesn't) much less be complete.