Exception does not seem to reach client

Ok, after further investigation, I found what has changed. My code is using TROSuperTCPChannel and has not changed. However, that very class moved from using a TROIndyClientSuperConnection to a TROClientSuperTcpConnection the latter being based on your own implementation of the communication channels, thus not depending on third party libraries.
I can understand the rationale behind this as you control all aspects of the code. However, there is a slight difference in your implementation, when it comes to the isTimeoutError: Boolean override.
That method is used inside TROBaseSuperChannelWorker.DoExecute like this:

      if not FBaseSuperConnection.isTimeoutError then begin
        {$IFDEF uROBaseSCHelpers_DEBUG_ARC}LogARC('--> TryReadByte=False. before Disconnect');try{$ENDIF}
        Disconnect;
        {$IFDEF uROBaseSCHelpers_DEBUG_ARC}finally LogARC('--> TryReadByte=False. before Disconnect'); end;{$ENDIF}
        Break; // disconnected
      end;

So, if isTimeoutError returns true, the failure to read one byte is ignored and the connection is kept open.
In the Indy case, the isTimeoutError method returns the value of FTimeOutError which in my real case above is set to True inside TROIndySuperConnection.TryReadByte because _ReadFromStack returned -1
With your own implementation though, the isTimeoutError method returns False because fConnection.LastError is not ETIMEDOUT. And indeed, inside TROSocket.CanRead there is no code that takes into account the fact that if RO_Select returns 0, then it’s because the timeout was reached. If I change the code to now read like this:

  x := RO_Select(fSocket + 1, @lFDSet, nil, nil, ptv);
  if x = 0 then
    fLastError := ETIMEDOUT
  else
    SockCheck(x);

Then the isTimeoutError method returns True and the connection is not closed, bringing the situation back to what it was with version 9.4
So, the real error lies inside TROSocket.CanRead but it also comes from the fact that TROSuperTCPChannel was changed to use another implementation.
And that does not remove the questioning about the computed timeout value, which to me, does not make sense in network terms.