Within the Framework's Base Class Libraries themselves, the documentation is pretty good about stating what is and is not thread-safe and the implementations ar

Within the Framework's Base Class Libraries themselves, the documentation is pretty good about stating what is and is not thread-safe and the implementations are generally quite good in that regard. Outside of the Base Class Libraries there is a lot of variability in thread safety, of course, so YMMV depending on what you're working with. That said, the thread safety isn't as critical in something like Node, at least not in the sense you'd usually be worried about, as the execution model is explicitly single-threaded. What you'd be more interested in finding (and pushing to improve) would be libraries that are externally bound but fail to provide an async option using the recommended async patterns for .NET. To be clear, these recommended async patterns and a good number of their proper implementations do not require hidden threads for their async behaviour, as when built correctly they are layered upon lower-level async operations that themselves do not require threads. One would hope to work towards a "turtles all the way down" kind of scenario where eventually nothing you are using blocks on anything external and instead uses the async primitives and layers them up such that no threads are needed for any async operations. Admittedly, as .NET goes there would be areas you can't achieve that goal, however, as some framework bits are secretly backed by threads (e.g. some serial port handling, when last I checked), but this is also true in the case of Node.js which itself maintains threads behind the scenes for use with otherwise-unavoidable blocking code. In either Node-style case the end goal is the same: to minimize if not eliminate the need for such threads, and in the .NET-specific case it should be largely achievable (to the degree that it matters) as there are plenty of building blocks with proper async options.