Yeah.
Current master (aka 2.2 to be) is a great improvement over 2.1 - I like it (mostly).
There is one ugly blemish on the 2.2 release though; that's the lack of fixing the networking issue where a failure to send the whole buffer results in corruption. You can't (won't) change the API in a 2.2 release, but what we have currently is *broken*.
I can think of one dirty workaround (may not apply to all OS's that SFML must support, but I'm throwing it out-there anyway) :
When being asked to send N bytes of data, peek the underlying socket to see if the socket has enough buffer space for N bytes. If it does, then send() is likely to succeed and there is no problem - if not, just return false at once and don't send anything. If peeking at the buffer size says there's room for N bytes but send then still fails (or only sends some of the data), then put the bytes into an internal buffer, sleep 1ms and retry the send - yes, ugly and will block the caller, but since we can't change the API to say "We sent M bytes" until SFML 3.0 - it's the best we can do - and it's better than being completely randomly broken like currently (IMHO).
Apart from that SFML 2.2 looks good to go from my perspective.
