The STL's build currently depends on checked-in OBJ files generated by an internal tool named aliasobj. We've started talking to the compiler back-end team, exploring whether they can make that publicly available at some point, but that may not happen soon. (@AlexGuteniev filed DevCom-1590983 and @BillyONeal filed VSO-1116868.)

In the meantime, we really need to stop using checked-in OBJ files, in order to secure our supply chain. This is my attempt to use the back-end's recommended alternative, the linker's undocumented /ALTERNATENAME option. (This is strictly more accessible to our GitHub contributors than the internal aliasobj tool.)

The main concerns are:

• Putting #pragma comment into <mutex> might result in user linker invocations being sent a whole bunch of identical directives. I didn't check to see whether this is actually a problem (they might be deduplicated?).
• ARM64EC and CHPE are weird. I'm currently using the fallback mechanism for them, since that's safe, and the only downside is a bit of performance.
• Clang doesn't appear to handle #pragma comment when it appears in the STL's object files, so I'm activating the fallback for Clang too. I haven't yet reported that as a bug.
• I tested this internally and x86 built and passed tests, indicating that /clr still works.

The changes are:

• Remove the stl/aliases subdirectory, and all of the CMake/MSBuild machinery mentioning it.
• Add the #pragmas to xonce2.cpp (which is conveniently already in the build system). x86 uses a different mangling from x64/ARM/ARM64; we can unify the latter. For ARM64EC and CHPE, we use the fallbacks. (I had experimental pragmas for them in an early commit but I didn't test them.)
• Add __std_init_once_link_alternate_names_and_abort(), a function that will allow us to drag in xonce2.cpp without a #pragma in the header. Then the linker will discover the pragmas providing /ALTERNATENAME. By wrapping abort(), we avoid paying any increased costs.
• In <mutex>, extend the forwarder workaround to ARM64EC, CHPE, and Clang. (I didn't check whether /clr could use /ALTERNATENAME, I simply assumed it couldn't.)

If aliasobj is made publicly available in the future, we can return to the old scheme, building the OBJ files freshly instead of having them be checked-in.

Although it's weird to use meow_clr forwarders in non-/clr scenarios, I realized that we need to keep the names for bincompat (because we permit old object files and static libraries, as long as the toolset used to perform the final link is newest). We could keep meow_clr for /clr and add meow_fwd for native but that would be verbose; I felt that just adding a comment explaining this was sufficient. This is a good lesson that we should try to name machinery based on what it does, not the specific circumstances that it happens to be used in today.