The whole idea of mixing speed/parity modes etc. down a single wire seems a bit perilous. In theory, the timing of RTU inter-message gaps and suchlike is set by linespeed. Even if cleverness could be worked into the binding to make safe allowances at the master end, you can’t predict how the slaves are going to cope.
The Modbus RTU specification states
"The transmission mode (and serial port parameters) must be the same for all devices on a MODBUS Serial Line."
which means that slave designers need not handle the case in any sensible way.
Reminder - it is possible the particular problem being attacked here is slave-based i.e. one of the devices is entering error recovery when it sees “gibberish” intended for another slave.
Also think that trying to get the binding to cope with it is essentially wasted effort for non-compliant cases. Personally I wouldn’t like to guess how well different hardware and operating system hosts would handle rapid reconfiguring of serial ports to make it feasible anyway.
The “correct” solution here is to set up two serial buses (would that just be a second USB<>RS485 adaptor in this case?)