>>48
Go ahead and try to do it at application level. I guarantee you'll quickly see why it's not as simple as you think. And we do have "libraries" for congestion control, message ordering and reliable delivery, it's called TCP and it's implemented in the kernel because that's the most efficient way to do it.
Reliable byte stream and datagram abstractions are for different things, it's not a question of "liking" one, it's a question of picking the right one for the job. You do VoIP or streaming media? UDP (or more likely RTP on top of UDP) is likely the correct choice. You want to transfer files? You want TCP (possibly FTP over TCP). Want to build a generic application protocol X? You want TCP 99% of the time.
Don't like the stream abstraction? Fine, use a message based protocol that gives you framing, like HTTP for example. Guess what they're implemented on top of? Yes, TCP.
And how is checking input buffer size not a programmer task? Who should do it, fairies? What you probably mean is that writing distributed applications, at least the networking parts, is not for generic application programmers. Which I completely agree, you want to pick a protocol that gives you what you need and then you want to get an implementation of said protocol with a nice and simple API by someone who actually knows how to write networking code.