to be clear, the i2c stuff is entirely separate from the serial communications to the computer i use to program the arduinos. basically, i have an old-school arduino setup using a max232 chip instead of the USB chip an arduino normally has (i'm not actually using an arduino board -- just the bootloader and the IDE). it's all in the basement 100 feet from my computer, so i had to use rs-232 for communication since usb range isn't very good.
down in the basement are two atmega328s connected via their i2c ports (pins 28 and 27). the master can read and write the analog and digital pins on the slave by specifying which ones it wants. it can also read and write the slave's eeprom. it cannot reflash the slave's firmware. to do that i have to throw a switch that decides which atmega's serial port (pins 2 and 3) is connected to the rs-232 cable. if you look at the source code in the link, you can see the details of the i2c communication. as far as i know, this is the only example online of reasonably-successful synchronous query-response communication between master and slave arduinos.
the reason it is so important to be able to query the slave from the master is that the master's code supports a sort of telnet-style interpreter to which i can send commands. these commands come to the master via rs-232 and can then be forwarded onto the slave.
as for the range of i2c communications, i've kept that bus short because it gets unreliable when it gets longer than a few feet. however, the rangefinder (which reads fuel level in an oil tank) has to be twelve feet away. to read it, i temporarily connect a "long range i2c" cable via quad bilateral switches for just the time necessary to make the reading. this seems to work okay.