fwiw, I tried the visibility annotation on the explicit instantiation with no luck - I think it's inherited from the template definition and from reading Clang code it seemed fairly hardcoded.

everything I can find about Mach-O weak bindings implied that uses internal to a dylib should resolve to the symbol inside the dylib though. I also couldn't reproduce with a simple test program using dlopen on our ICU build while linking to Foundation. so I need to poke more at stuff there to figure out the true root cause of why this is happening to .NET

ODR when it's something pervasive like libc++ that is linked directly into programs and can easily show up in ABIs etc. is one thing to step away from and say that we're going to just use the system one or prefix our symbols, but when it's internal implementation details of system stuff leaking that aren't otherwise exposed to consumers... TBH if it's not the result of .NET doing something really weird then it seems like a screwup on Apple's part to not use the platform facilities to hide that kind of thing, but it'll also really suck to have to play whack-a-mole and have existing binaries break on new OSes.

since I don't have a minimal reproducer yet I'm optimistic that in the usual case this stuff doesn't actually leak and that it's not as bad as it sounds. but I will need to dig some more. I'm also surprised if nobody other than Nixpkgs has run into this which increases my feeling that it's something messed up about .NET.