Thanks JP, that's very helpful. That Windows FDTI driver overriding the SynSer timeout setting explains the behaviour. It's useful to know where that driver might be adjusted, but in practice if I can work around asking my eventual users to do anything "advanced" (especially anything o/s specific) that would keep life much simpler.
(Apologies for the typo btw, it is indeed revcBufferEx that I am using)
At the moment this is a quick lashup mainly to check out the hardware and UI so, no, the code is pobably far from streamlined! Each master-slave transaction runs in its own thread, returning the result to the main thread which may then respond by launching another bus query, depending on the message data it received previously. But the time overhead of the port 'open' and 'close' operations is (on Linux, not measured on Windows) around 100ms, much longer than most of the bus exchanges, so it seems to make sense to keep the port open until the current sequence of bus exchanges has completed.