You're right, I was a little hung up on the 119 addressing. I've used I2C a lot, at least in its SMBus implementation, for interfacing with laptop batteries, and spent hours looking at its timing and protocol... I've just only really dealt with one device at a time 
Really, the 119 address would no longer be a "broadcast", it'd be the processor sending commands to the board that's holding the address line high. Maybe this could be the sequence of events at the assigning-time (after one board has picked out that it's holding the address line this "round"):
- all other devices are in "delay loop" mode while they see the address line is high, so they aren't listening
- processor sends "hey, device 119, identify yourself" (start -> address 119 -> "read" -> read expected bits of information -> stop)
- device sends "i'm a relay board, my programmed number is 32"
-- if the response is garbled, perhaps 2 modules saw the line low at the same time; simply discard the data, send an error response, and the line should go low to get another request; those erroneous boards would just get re-queued within the next few milliseconds. - processor sends "hey, device 119, take address 2." (start -> address 119 -> "write" -> write its new address -> stop)
- processor sends "hey, device 119, did you get that?" (start -> address 119 -> "read" -> read the new address -> stop)
- processor remembers that a relay board is present with ID# 32, previously programmed to its EEPROM, and is on I2C address 2 now.
- device goes to address 2 and releases address line
- next device leaving delay loop sees that address line is free and begins the cycle again (and by holding high before the others come back from their delay, it effectively "queues" the boards to be addressed).
It should be able to address all the devices on the backplane within 1 second, even...