According to https://securitydriven.net/inferno/

[Xyncgas]

For example, if you follow “Internet advice”, you are likely to come across the Bouncy Castle c# library (a typical StackOverflow recommendation). Bouncy Castle c# is a huge (145k LOC), poorly-performing museum catalogue of crypto (some of it ancient), with old Java implementations ported to equally-old .NET (2.0?). If you have a crypto archaeology itch, Bouncy Castle will scratch it. However, for typical practical purposes a new, modern, trusted, general-purpose .NET crypto library is required.

[ProIntegritate]

No one is forcing you to use old algorithms BC is still better than the stuff offered under system.security.cryptography.*, to have older algorithms available when interfacing with older services that can't be decommissioned.

Vanilla .NET6 doesn't even have SHA3 (Keccak), just recently got AES-GCM and it's DH implementation isn't compatible with itself, meaning the exact same ECDH code in .NET6 can't communicate from Windows <-> Linux.

See "ECDH native interop" @
https://learn.microsoft.com/en-us/dotnet/standard/security/cross-platform-cryptography

BC is also multiplatform and compatible with itself, supporting .NET 6+ on Windows, Linux and probably Mac (haven't tested it), as it isn't dependent on an underlying crypto API, which is the problem with Native .NET CryptoAPI explained above. And there is also a Java version of it.

[dghgit]

Thanks @ProIntegritate I'm closing this one off now. I'd probably also add that I'm not sure I'd classify the post-quantum suite as a museum catalogue set although to be fair to the original commentator the comment was based on a much earlier version of the libraries (not that I would entirely agree there either, but it would have taken more than a first glance to realise).