On the build of the last three boards, one of the boards refused to respond to "pings" on the I2C bus to one of the IS32FL2728 chips. The "ping" is just a read command that gets no data. The other 8 boards had no issues on this with both chips responding as expected through the LTC4316 address translater chip. The board accepted write operations and commands to both controllers normally. The I2C address translation values were picked to not collide with any of the other 8 controllers on the bus. There are some special purpose reserved addresses at the extreme low and high address areas and I avoided them as well.
Thinking that if one of the addresses on the board did respond and the other one did not, the I2C bus was probably good and the IS32FL3738 chip that was not responding had a problem. After lots of un-rewarding inspection of the board and verifying power and I2C goodness to the chip, I replaced the IS32FL3738 chip that was not responding. No joy, it still did not respond. In a fit of irritation, I swapped a few passive components related to the chip with similar results.
I checked the soldering around the address translator chip and all looked fine. Looking at the I2C signals with a scope on both sides of the translator chip, looked about as good as one would expect of an I2C bus with 18 devices on it. I did not put testpoints on the board that would have made it easier to hook a bus sniffer up and examine the translater output traffic, so that was not done.
The application that I am using these parts for does not need to read anything back from the IS32FL3738 chips, so I put the problem aside for a few days. Leaving something that glaring wrong on a project bothered me, so I did not decide to just ignore the issue.
The way that the translator chip was configured, the responsive chip was at 8 bit address 0x5A and the missing response should have been at 0x50. It occurred to me that for some reason, the LTC4316 address translator chip might not be translating the address correctly. I searched the data sheet on reserved addresses on the I2C bus and 0x50 (7 bit 0x28) might be a reserved address. There was no mention of it. I started digging through the I2C spec and saw a mention of a strange PMBus zone read protocol involving address 0x50, but no details. The PMBus document did not mention it either.
Figuring that the problem was only seen on a read operation, it might be related to that zone read thing, so I changed the translation address to put it at 0xD0 and 0xDA. Bingo, both IS32FL3738 chips responded to the ping.
10/10/2020 Was digging through the source code for my address ping tool to make modifications to it for another task, and figured out that the address ping tool treated the 0x50 address as a "special function" address and inhibited accesses to it. I wrote that tool several years ago, and had forgotten how I had inhibited the tests on it.