Display Name

@Fausto I figured it out. Clock speeds for the devices were mismatched. The solution was to run a second I2C bus on GPIO pins 17 and 27. For anyone encountering this issue, see below for details.
The MCC 152 datasheet specifies an I2C clock speed of 400 kHz (see screen shot below):

My other devices are 5 kW, XP Power HPT5K0TS048 power supplies. The communication specification indicates a clock speed of around 100 kHz (see screen shot below).

 
This clock speed mismatch is my best guess as to why the HATs prevent me from communicating with my 5 kW power supplies. I still believe that, for the same clock speed and different address spaces, the HATs should *not* prevent communication to devices outside their address spaces, so long as the bus is small enough for the RPi to drive it. However, MCC has yet to confirm this.
In any case, the steps to setup a second I2C bus are fairly simple. These steps are as follows:
First, read the informational file within Raspberry Pi OS at /boot/firmware/overlays/README. Overlays are firmware level specifications to modify and set hardware functionality on boot. The relevant overlay for a second I2C bus is described by the `i2c-gpio` overlay:
Name:   i2c-gpio Info:   Adds support for software i2c controller on gpio pins Load:   dtoverlay=i2c-gpio,<param>=<val> Params: i2c_gpio_sda            GPIO used for I2C data (default "23")         i2c_gpio_scl            GPIO used for I2C clock (default "24")         i2c_gpio_delay_us       Clock delay in microseconds                                 (default "2" = ~100kHz)         bus                     Set to a unique, non-zero value if wanting                                 multiple i2c-gpio busses. If set, will be used                                 as the preferred bus number (/dev/i2c-<n>). If                                 not set, the default value is 0, but the bus                                 number will be dynamically assigned - probably                                 3. Specifically, I need to add the following line to /boot/firmware/config.txt to create another I2C bus on GPIO pins 17 and 27 (modify pin numbers and bus number to suite your needs):
dtoverlay=i2c-gpio,i2c_gpio_sda=17,i2c_gpio_scl=27,bus=3 Note that I do not need to specify the clock speed, as the default is around 100 kHz (which is what I want for my power supplies). Moreover, it is unclear if line order matters in the config.txt file. I put my dtoverlay configuration right below the main default I2C and SPI activation portion of the file.
The new bus is implemented on reboot, and you should see another I2C bus at /dev/i2c-3 in addition to /dev/i2c-1 (along with the lower level EEPROM I2C buses).
Second, you will need to add your own pull-up resistors to the pins you choose to use for the second I2C bus. I used 1.8 KOhm resistors between the pins and 3.3 V. The Pi-EzConnect HAT by Alchemy Power makes soldering in through-hole resistors very easy. I chose 1.8 kOhms because that is what is used on the dedicated I2C bus on GPIO pins 2 and 3.
Now, I can scan both buses and see the MCC 152s on bus 1 and the 5 kW power supplies on bus 3.
I am interacting with the 5 kW power supplies via the Python smbus2 package. To do this, I simply specify bus 3 when instantiating my SMBus() object.
 

@Nick Wright and @Fausto, I've figured out the issue. The problem was that I have a connector that hot-plugs the encoder into the DAQ as pictured below.

As mentioned in previous posts, my sensors are active 24 VDC, and the inrush current on the power lines when hot-plugged was coupling transient voltage into the signal lines (see scope trace below). These transient voltage spikes were causing the PCAL9554B on the MCC 152 to fail. The first symptom noticed under these failures was lack of I2C communication. (As an aside, I was able to purchase this IC and repair the failed MCC 152 HATs, which I am now using as sacrificial test boards.)

The solution was a custom PCB that attaches each signal line to a rail-to-rail transient voltage suppression (TVS) diode (see photo below). The TVS diode array used was a Semtech SRDA70-4. This diode array is "rail-to-rail" and the clamping voltage is set by the reference supplied and the diode forward bias voltage. I am referencing mine to 3.3 V. Note that this will put transients on the 3.3 V source. For this reason, it is important not to connect this reference to the CM4 3.3 V GPIO pin (I tried this first, and the 3.3 V transients caused the CM4 to reboot after every hot-plug attempt). I am now pulling the 3.3 V reference from the dedicated output from the 3.3 V DC-DC converter on the RPi I/O board. Note that this converter is for the PCIe connection. I am not using PCIe, so am pulling the 3.3 V power from a PCIe extender cable connected to the I/O board. In the near future, I plan to develop my own I/O board with this dedicated 3.3 V trace to a terminal block (without the other PCIe traces). For now, pulling from the PCIe extender cable is sufficient. For anyone interested in this fix, the custom TVS PCB KiCAD project can be found here. The custom board is not meant to mount in the HAT stack, feel free to modify and use as needed.