From the comments, it seems there is no actual i2c device that must be used, communication is always initiated by the central device, and UART lines are available on both ends. In that case I don't think there is any advantage to i2c. Half duplex RS485, for example, would use the same number of lines and perform better all around.
This answer is just for completeness, and because the question title says it. This is to address extending the range of i2c. I am not talking about the repeaters themselves, just general i2c-in-a-cable. To be totally clear, this entire scheme is not recommended, more like if you have to do it, here are some things that could help.
First of all, here is an app note from NXP on the subject.
I tried to catalog various i2c issues I became aware of in a previous post, here.
Doing extended range i2c would make some limited sense to me in a situation where a sensor is used that requires i2c, speed is limited, and especially if a working design already exists, but the range must be increased -- e.g. from a 100mm internal connection to several-meter remote sensor. I went through this exercise with 100kHz data rate and did get it to work well (tested to 15m+ in a M8x4 SAC cable, with both PVC and PPE inner insulation, and the unfavorable wire arrangement. Deployed with 5m length to be safe).
The main points IMO are to choose drivers with a relatively low dV/dt limit on each end, to avoid placing SDA and SCL next to each other in the cable (whether linear or circular), to optimize the pull-up current for your setup, and minimize capacitance in the cable. If the cable format is fixed by specification, different inner insulation materials and thicknesses can still change this quite a bit.
In my case, the MCU I was using had dV/dt limited open-drain driver in i2c mode, but the sensor did not, and the cable was made the "wrong way" for legacy reasons. On the other hand I had Vcc = 5V, which gave a little extra margin vs the crosstalk glitches.
I used constant current pull-up, about 1mA on each end of each line, via PNP simple current mirror. Added 68 ohm series termination. Plus ESD protection using a diode array designed for USB, which fit nicely - although big caveat, the devices built for this project were not tested for ESD, to the best of my knowledge. The order of the parts was, ESD protection on the "outside", then the 68ohm, then the pull-up mirror, then finally the chip with the i2c.
Another note is that the series termination won't work when the transceiver is high (and thus high impedance). The current-mirror pull up arguably helps this to a limited degree, on the theory that the output transistor of the mirror is initially in saturation when the falling edge arrives. I'm not too sure how much effect this really has, but in any case, we are getting some termination at the source.
For the crosstalk victim line, however, the constant current pull-up makes a noticeable difference. It does this by sourcing the full current almost immediately, whereas a resistor pull-up would source current only in proportion to how much voltage had already been dropped. As a result, the voltage drop on the high victim line from the same transition on the source line is reduced by something like 50% vs a resistor sized to produce the equivalent current in the low state. The rise time improves too, as you get a constant slope rather than the familiar RC shape.
Despite all this I was not really happy with this design, and if I had to do it over, I would use some kind of differential i2c extender chip.
