Here is what I experience:
For 1 Teletype + 1 TXo + 1 TXi, things are solid. You can hammer it hard and you can type incorrect addresses without locking up the i2 bus. Totally fantastic!
For a 1 Teletype + 4 TXo + 2 TXi + 1 Ansible configuration without any changes to the i2c resistance, you will be able to send commands to the TXo and Ansible no problems - as long as your addresses are correct. If you type an incorrect address, the Teletype will hang. If you try reading from the Ansible or TXi, it will work sometimes - but ultimately lock-up (especially if you are reading from the M script). Crap.
I was able to make that massive configuration quite stable by activating the internal pull-ups on the TXi closest to the Teletype (and only that device). Then, it was back to the performance of the small configuration. No lock ups on writes to unknown addresses and no lock ups on reads. It is awesome!
In the "stable" states listed above, I could pound the hell out of the ecosystem in various unreasonable ways. You would start to see the throughput limitations in the extremes and could get things to start being wonky when you are trying to send and retrieve at a rate that is faster than the Teletype and bus can service. I agree with @scanner_darkly above that this should just be accepted as a limitation of the system.
I'm happy to turn on the pull-ups on the TT and see how that performs in the two scenarios. This would be the easiest solution as no one would have to modify their Teletype, install some sort of weird dongle or install different versions of the TX firmware depending on their bus configuration.
To do that, I'd love to have the answer to which to turn on. The values that @tehn provided above aren't known by the compiler (PA09 and PA10). I'm fairly certain he meant A09 and A10, but I don't know the pin configuration and am hesitant to just start trying stuff without that information.
Thanks so much for everyone's interest in this.