Thought I'd stick my library here like muchaho. GonzoNet is a library designed for large scale distributed networking (think MMO.)
It currently only supports TCP, UDP might be added in the future (UDP is uncommon for MMOs and so wasn't considered important when designing)
Unlike a lot of other libraries out there, GonzoNet does not impose a protocol on an application, and so is more like a high level wrapper on top of .NETs asynchronous sockets.
The code hasn't been cross compiled, but it uses no special namespaces that you shouldn't be able to find in Mono.
It has been tested with up to 300 concurrent users in a real setting (Though no actual "gameplay" was involved, as the project it is used for hasn't progressed further than the character creation/selection/login stage.)
GonzoNet supports authentication and encryption using Diffie Hellman EC, which was actually suggested to me on these boards!

When I think of "large scale" socket wrappers, I'm usually aiming for more like 50,000 simultaneous (low-traffic) connections. If they're all heavily active, I should be able to do at least 10,000 before I start seeing networking take a prohibitive amount of CPU time.

Since this library is aimed at scalability, what design choices were made specifically to allow scaling? What are its performance characteristics in actual large scale scenarios?

Well, since this library is so low level, scaling will be mostly on the application design level.
However, I've tried my best to guarantee 100% thread safety, so that an application (typically server) can be designed to be scalable without worrying about the low level architecture.

As for performance characteristics, I've tested it for 300 simultaneous users (see OP.)
I guess I really should write a test case that can spawn 10,000 clients, bit haven't gotten round to it yet.

However, I've tried my best to guarantee 100% thread safety, so that an application (typically server) can be designed to be scalable without worrying about the low level architecture.

I think ApockPIQ is trying to tell you, subtly (using the Socratic method :-), that you probably shouldn't "release a library" without actually having significant experience in how to write the kind of code that goes into that library.
Scalability for low-level networking on modern servers have to do with lockless worker queue implementations and asynchronous/event-based I/O, putting exactly one thread per CPU.
"Guarantee 100% thread safety" seems like you're using a fair bit of locks, which probably is not what someone who really was looking for a high-scalability networking library would be looking for.

Hmmm.... ok, maybe I shouldn't ask, but do you have an alternative I should be using instead of locks?

As for asynchronous IO, this library is written directly on top of .NETs asynch sockets.

I already stated that in the OP.

Lock-free queues are generally better where you can (safely) use them.

Perhaps I should ask the question another way:
- Why should I use your library instead of straight async sockets?
- Why should I use your library (or trust you) as opposed to some other library (and the author of that library.)
For example, for C#, the Lidgren library has been around quite a while, and has been hardened by being used for real in several existing games.

Note that I'm not questioning you -- I'm trying to help you formulate your market communications in a way that's clear!

Lock-free queues are generally better where you can (safely) use them.

Perhaps I should ask the question another way:
- Why should I use your library instead of straight async sockets?
- Why should I use your library (or trust you) as opposed to some other library (and the author of that library.)
For example, for C#, the Lidgren library has been around quite a while, and has been hardened by being used for real in several existing games.

Note that I'm not questioning you -- I'm trying to help you formulate your market communications in a way that's clear!

1. Easy - because using straight async sockets means you're probably going to end up writing some kind of wrapper on your own anyway. I already did that! :)

2. GonzoNet has already been used in Project Dollhouse, which has 331,180 LOC (including GonzoNet) and been found to work quite nicely. However, I need to write more test cases to come up with more hard data!

PS: Thanks for guiding me onto lock free queues! :)

designed for large scale distributed networking (think MMO.)

When you say things like this, you have to be able to answer the question: how many MMOs have you built with this networking library (or the primordial form of this library) and what are their traffic, architecture and concurrency statistics?

Anybody can say they've designed a thing for MMOs, but until you can show it's actually worked in an MMO of suitable scale, you're going to create nothing but skepticism with a marketing point like that.