Could you try re-wiring your interface so that it uses CTS instead of RI and test if this works (don't forget to change the command line in the RespeQt settings)?
The "Bugfix for Hardware Handshake under Windows" commit (which is in r3 but not in r2) could be problematic
On 16550 serial ports the RI line triggers only an interrupt/event on the trailing edge (i.e. at the end of the command frame), CTS and DSR trigger interrupts on both edges. From a first glance it looks like the code could need the event on the leading edge (beginning of a command frame) which will never happen with RI on a "real" serial card (USB-serial adapters are different).
The commit which you mentioned is actually a bugfix for Windows (Linux version worked OK).
The way the SIO processing should work is:
1) wait for an event on the leading edge (start of the command frame)
2) clear the input buffer
3) read and process command frame
4) go to 1)
Before my commit, the code was waiting in point 1) for any change (rising or falling edge of the command line).
When ATARI was for example writing data to a real floppy, RespeQt was interpreting wrongly data frames as command frames (when triggered on falling edge),
I checked the corrected version with my Laptop with a real serial port and a SIO2PC cable using CTS (http://atariki.krap....ndex.php/SIO2PC).
Now it all makes sense, considering what you said about RI signal.
Knowing that, it is simply wrong to build a SIO2PC cable using RI signal...
Such cable would never work with RespeQt under Linux, where we explicitly wait for a rising edge.