Also, your library provides some socket API, and therefore, if it is accepted, I don't expect any other socket class in Boost in the nearest future, which means I would expect your classes to nicely wrap all of sockets, not only acynchronos ones.
I've been thinking about these issues since your email. My feeling is that a use case doesn't have to become very complicated for the asynchronous operations to be beneficial. But where a developer's needs are simple enough, I suspect that's also when they are going to want to use an iostreams-based interface. Since iostreams basically enforce synchronous operation, this seems like a sensible place to hide the demuxer and asynchronicity away.
I strongly, strongly agree. You can build a robust synchronous implementation, iostream based or not, on top of an asynchronous foundantion. The reverse is difficult and tends to be non-scalable. Dave Moore