bypassed in what way? the symbols here don't have a namespace involved (because they're defined, just weekly), and dlsym with a specific library looks symbols up in that library. I think the global namespace only gets used for the weird weak symbol deduplication case or if you explicitly ask for it.

I think using darwin.ICU like a normal ICU doesn't make much sense, since Apple specifically don't export the non-monolithic version at all - so consumers that expect Apple patches and consumers that expect to consume it as separate libraries are disjoint.

(do we actually know that .NET wants the Apple patches? I vaguely recall we saw it default or something without in the past - but that is quite plausibly due to the very same weak symbol issue we're running into now.)

I'm guessing that making a monolithic .dylib might work around what we're seeing here. it seemed like there might be other divergences in his Apple builds their ICU to what we're doing too. though ultimately they have the same weak symbols of course, which is what's causing the problem here - it's just like the weak C++ symbols that were causing a problem on the old SDK in the past 🙃

but I would probably check if U_I18N_API on the explicit instantiations and -no_weak_exports to the linker to guard against it works first, because if it does that's probably upstreamable to ICU, and it seems like we really want -no_weak_exports for everything that has symbols that are also in the dyld cache, because otherwise nothing stops things like this happening, C++ or not. C++ might be the most common way to "accidentally" get weak symbols but it's definitely not the only time they'd come up. (admittedly weak exports are a weird case and I don't fully understand yet how they don't mess up two-level namespaces in general.)

it would be nice if we could tell ICU to just hide all the C++ API but aim not sure that's a knob their build system supports.

still thinking about what other more robust options we might have