Trying to do with with IIC is a bad idea. IIC is really meant for communication between chips on a single board. Since the maximum required current to pull a line low is limited, the lines are relatively high impedance (a few kΩ). This means they can pick up noise easily, which is a serious issue when running in unshielded cable in the walls possibly right next AC power wires.
I would use CAN for this. CAN uses a single twisted pair pulled together with only 60 Ω at any one point, and the signal is differential. That means most of the inevitable common mode noise that will be picked up due to capacitive coupling can be cancelled by receivers. CAN running at 500 kbits/s can cover something the size of a ordinary house.
Many microcontrollers are available today with CAN built in. You usually need a separate physical tranceiver chip (like the common MCP2551), but the lowest few layers of the protocol are implemented in silicon in the CAN peripheral. The firmware interacts with the CAN bus at the level of sending and receiving complete packets. The collision detection and retry, checksum generation, details of the bus packet signalling, received checksum validation, and clock drift adjustment are all handled for you.
Don't fall for RS-485. That's a relic from a bygone era. It also uses a single differential signal like CAN, so also has good noise immunity. However, people usually fall for RS-485 because it looks "simpler". This is only because they don't look at the whole system. First, it's not really any less complex electrically. You will still need some kind of transciever to drive and receive the differential signal. Whether you have a RS-485 transceiver connected to the microcontroller's UART, or a MCP2551 connected to the CAN peripheral is pretty much irrelevant in terms of cost and hardware complexity. The big difference is that RS-485 leaves you at the raw byte level (via the UART). This means to implement any meaningful and robust system, you have to invent your own protocol to handle collision detection, decide how to handle retries, packetization, checksum generation and checking, flow control, etc. You can use a single master architecture, but getting the details right is a lot more tricky than people think that haven't analyzed all of them carefully. With CAN you just send and receive packets, and the hardware takes care of the details.
Best Answer
I don't think a foot or two of wire connecting digital signal wires mandates very much design considerations. The current flow in digital signals is so low and your wire length is so short that inductive effects are negligible. Likewise, there will be virtually no loss to the wire resistance. And with very small current flow comes very little radiated energy, so you shouldn't have to worry about generating EMI. There's always a danger of absorbing EMI from nearby devices (the wire acts like an antenna), but I doubt that will be a problem for your situation.
The main consideration I would think about is the danger of ESD events on the wires. The mere presence of the wires off the boards increases the chance of contact with charged objects (most likely your hands) that can send transient voltage spikes down the wire and into both boards. For that reason, you never want to connect the pins of the microcontroller or other sensitive components directly to a connector that goes off-board. At a minimum, for digital lines, I would recommend a resistor in series with the connector and an ESD-rated TVS (Transient Voltage Suppressor) diode to ground. And that feeds into a digital buffer IC, which, finally, connects to the pin on the microcontroller. The resistor can be any large value in the kiloOhm range and the TVS diode should have a breakdown voltage a little higher than the digital high voltage on the lines.
You can get much more sophisticated with ESD protection, but that should give you "good enough" protection.