Quartz routers RS422 problem

I love Quartz for routers - they are a small English firm (now owned by Evertz) and they really pay attention to detail - like MurrayPro and Crystal Vision you can talk to the designer/programmer and get sense. I see their routers in more OB trucks than most and having put in a few they seem more reliable than Probel et al. The control system and programming tools are very straightforward (Leitch could learn a thing or two!) and the fact you can download to the master level from even a control panel hundreds of meters from the mainframe is fantastic. At MTV last year it saved me lots of shoe-leather!
Now - I put in a simple SDi/RS422 system at five and they had this problem that was hard to replicate - When one of the editors assigned a VTR to one of the Final Cut workstations another VTR route would drop (only on the RS422 level). This meant that in effect they could only use one VTR at a time. I couldn't replicate the fault. Quartz suggested;

• Re-load the router config in case of corruption
• Move one of the VTRs to an unused port and re-programme to reflect the change - in case a cross-point had gone faulty

I tried both of these, but since I couldn't provoke the fault before I started (neither could Stuart, their senior engineer) I felt like I was going through the motions a bit. Stuart even went as far as to suggest it was finger trouble! In the end I saw it happen and it was thus - The editor routes the VTR to the FCP and then he routes the FCP back to the VTR - this is sensible as he doesn't want to have to go back to the control panel when he does his layback. I hadn't appreciated this and had always just routed a VTR into the FCP only for testing. It did seem that when you route a VTR in AND out of an FCP and then do it with another VTR/FCP combo it drops the first route. Everyone at five's reaction was that the RS422 level was having trouble treating each device as a source and destination but this is bogus - even though a VTR is only one hole on the back of the router all P2-protocol devices know about Tx/Rx swaps and that wasn't the answer.
Thinking back to the first or second series of Big Brother I rememeber a similiar problem - it all comes down to the fact that the Quartz control software makes the serial port router look like a set of sources and destinations by using a two-pointer buffer. If you fill that buffer with two routes that refer to the same device you run the risk of subsequent routes breaking that relationship. The solution is to re-sort both source and destination tables so that all RS422 port definitions are in exactly the same places in the tables for the same devices - something you'd never have to worry about for other signal standards. By doing this the buffer never gets monopolised by a single device and the problem is solved.
Now Quartz told me this (reluctanty) back in 2001 and to my suprised it's still an issue - it's also still not documented!