I don't know how they implement the timeout, but assuming they use the  
underlying socket timeout, then there's a good reason for disconnecting  
the socket after a timeout, as the socket is in an indeterminate state at  
that point.

So, it's likely that this change in behavior is actually a usability  
bug-fix, so that inexperienced socket programmers don't go trying to  
continue to use a socket on which a timeout has occurred.

Note that this receive timeout is different from using a timeout in other  
methods (e.g. Socket.Select()).  You can implement a timeout in a variety  
of other ways that don't invalidate the socket.  But the ReceiveTimeout  
property likely sets the socket's receive timeout option directly  
(setsockopt(...SO_RCVTIMEO..)), and that's what will invalidate the socket.

Pete