#Koepel many thanks for all the very helpful and relevant info. Yes, I have known since childhood the formula for resistors in parallel vs that for resistors in series... but that's about the extent of my grasp of circuit theory 
The conversation illustrates for me the finest aspect of the Arduino community -- high quality mentoring. I'm very grateful for the tutoring and will be investigating further, learning how to use my pocket scope, etc. This thread is now bookmarked permanently as I know I'll refer back to it more than once.
Thanks to MorganS too, I do have the cheap USB scope as mentioned, I just have to get comfortable using it. Takes some practise. So much stuff to learn, not enough time!
UPDATE: The controller worked flawlessly for a number of days, then suddenly crashed again with i2c issues. It now looks like Leo2 is no longer responding at all on the bus, despite numerous power cycles. So I took a deep breath and figured out how to get my xminilab portable into Logic Analyzer mode Thanks to the xminilab I can see the failure with my own eyes. All other devices are talking to Leo1 correctly, and the protocol sniffer shows me that traffic (in hex bytes). I can see Leo1's attempts to contact Leo2 at the end of startup, sending to address 8; and I can see that Leo1 never receives any ACK. So I would say that the i2c bus as a whole is working fine, but Leo1 in particular is having a problem -- whether that be loose jumper wires or whatever it may be. I did notice that the voltage on the i2c bus when I tested it was a bit less than +5, like 4.8. I am not sure whether this is because the xminilab did some averaging of the signal on the bus, or whether the voltage is a bit droopy. Thanks again for the advice and encouragement... now I've got past most of the intimidation factor, I'm looking forward to using my pocket scope and improving my troubleshooting skills.
UPDATE 2: The debugging process was interesting; the i2c bus failed in various ways, changing over time (probably as I handled and moved the enclosure). At one point Leo1 could no longer talk to any of its slaves. I decided to suspect Leo2 since the trouble began there, and unplugged it from the i2c bus, at which point everyone else came back online and bus traffic was normal. But when I plugged Leo2 back in, guess what -- everyone including Leo2 was now communicating successfully. My conclusion -- I'll be more sure of this if I can repeat this "fix" -- is that the issue is with the mechanical connection of jumpers to the F header on Leo2; the duinos are mounted upside down so gravity is assisting the pins in loosening, and the entire bike vibrates continuously in use, which may explain why everything works great for N hours of use and then goes sideways (as one or both connections start to get sketchy).
It may be that the jumpers (cheap ebay stuff) have slightly undersized pins, or...? but at any rate, at this point it looks like the bus itself (despite the absence of pullup resistors, p/s decoupling caps, etc) works just fine, but Leo2 has a specific problem with its physical connection. As we used to say in my working days, "Theory of Wire." So MorganS may get the prize for Right Answer on this thread. In the next version of this controller I think I will use a protoboard shield (these seem to be a good tight solid fit into the headers on the duino) and solder the wiring harness to that, rather than the very prototypish (and apparently unreliable) flying-jumpers method I used for the beta version. I have found that putting a slight bend in jumper pins sometimes improves their grip on the socket, so for now I'll try that.
For those building their first moderately complex Thingy, I should mention a few regrets I have about the beta build, lessons learned:
- I should have brought out test points for crucial features such as vcc, ground, SDA, SCL, accessible from the outside of the enclosure. These test points should have been designed for easy/secure contact for scope and multimeter probes.
- I should never have relied on USB power for 2 linked Arduinos in one enclosure each with its own USB connection. A single wall wart or other external p/s was the way to go.
- I should have provided a socket each for pullup resistors for SDA and SCL, so I could try out various resistor values w/o having to unmount the enclosure from its place on the bike.
- I should probably have put a nice big capacitor from VIN to ground (according to my recent reading).
- I should have separated, as far as possible, the wires for SDA and SCL, to avoid crosstalk.
- And because the enclosure in actual use is mounted on the bike handlebars, it doesn't sit conveniently on a workbench and a conventional multimeter is almost useless -- you need three hands! -- so I should have invested in a pen multimeter long ago (got one on order) and I need to make a velcro/elastic wrist band for my Xminilab Portable as well for hands-free use.
I hope that these coulda-woulda-shouldas are instructive for others making their way up the learning curve.