NXP LPC11E68JBD48E Microcontroller I2C1 is Master. I2C1 is in chapter 13.  I2C1 is in Master Transmitter Mode.
http://www.mouser.com/ds/2/302/UM10732-315822.pdf

NXP PCAL6416A I2C 16-bit I/O Expander is Slave.  https://www.nxp.com/docs/en/data-sheet/PCAL6416A.p...

I2C1 Block in Microcontroller is initialized successfully.

Step 1.  I2C1 block is in master transmitter mode because I2C control Register STA bit is set to 1.  See attached step1_Master_Transmitter_Mode.png file.   step1_Master_Transmitter_Mode.PNG

Step 2.  Microcontroller I2C1 block transmits START bit.  After the START bit is transmitted, the Serial Interrupt(SI) bit in I2C Control Register is set and
and STAT register in microcontroller I2C1 block contains status of 0x08.  See attached filename step2_start_bit_sent.png     step2_start_bit_sent.PNG

step 3.  The status 0x08 is used to vector to a state service routine.  This routine loads the slave address and Write bit to the DAT register.
See attached filename step3_status_0x08_state_handler.png  step3_status_0x08_state_handler.PNG

step 4.  Slave address and Write bit has been transmitted and negative acknowledgement(NAK) is received from slave.  The STAT register has status of 0x20 and
microcontroller fires interrupt on this status value.  See attached step4a_NAK_from_slave.png file and step4b_NAK_handler.png    step4a_NAK_from_slave.PNG            step4b_NAK_handler.PNG

This problem occurs the very first time Master tries to communicate with slave.

The previous hardware works fine with this microcontroller and NXP PCA6408AHKX I2C 8-bit Expander chip.  When this byte is written to I2C register, ACK is received.

New hardware is same as previous hardware except 16-bit I/O expander instead of 8-bit.

What might be the problem?  Is it hardware or software?  What are usually reasons for NAK in I2C communication?

NAK is an appropriate term: Negative Acknowledgement. It's sent when you heard what was sent, just didn't like what it said. Since the protocol is a bus, getting a NAK means the chip is being addressed correctly, but the message content isn't valid.

I really like the PCA series, used them in many builds, but not these.

>>  chip is being addressed correctly, but the message content isn't valid.     The message content is only address and write bit.  Please see following text from microcontroller manual chapter 13.

"The first byte transmitted contains the slave address of the receiving device (7 bits) and the data direction bit. In this mode the data direction bit (R/W) should be 0 which means Write. The first byte transmitted contains the slave address and Write bit. Data is transmitted 8 bits at a time. After each byte is transmitted, an acknowledge bit is received."

The byte I'm sending is 0x42.  Seven most significant bits are slave address and least significant bit is write direction bit.  Please see attached filename byte_sent.pngbyte_sent.PNG

Silly question: Is the ADDR pin connected to VCC or GND or floating?

0x42 means ADDR is connected to VCC. See https://www.nxp.com/docs/en/data-sheet/PCAL6416A.pdf section 7.1

Good question:  According to schematic, ADDR pin is connected to VCC

Attached are scope screenshots for existing hardware and new hardware.

With existing hardware, slave sends an ACK.

With new hardware, after START condition is transmitted, master fires an interrupt to inform software that START bit has been transmitted but I don't see it on SDA line.  I'm triggering on START bit.  What might be the problem?
Some inputs in the I2C expander chip are floating.  Is this preventing the START bit to appear on the SDA line?
From I2C expander datasheet:  "External resistors are required for inputs (on P Port) that may float.  Also, internal pull-up or pull-down may be used to eliminate the need for external components."

lpc11e68_Master_pca6408_slave_addr_byte.PNG

lpc11e68_Master_pcal6416_slave_no_start_bit.PNG

first issue - no clock. Cannot have a start bit without a clock.

External resistors are required for inputs (on P Port) that may float.  Also, internal pull-up or pull-down may be used to eliminate the need for external components.

It is pretty common for MPU pins to have an internal pullup you can activate. 

I would first write some simple code to wiggle the SDA and SCL lines. This will help you know what the register GPIO settings are. The I2C device should take over these lines, but it will give you the assurance that the connections are solid - no issues with poorly soldered pins.

But the most obvious thing is you don't have SDA and SCL lines wiggling.

1st new board -  saw NAK in software

2nd new board -  SCL and SDA not wiggling at all

3rd and 4th new board -  I2C communication appear to be working as expected.

Are all boards eval boards, or are you developing the boards?

One of the things I love is bringing up new boards. I get to look at the EE and say "It's your problem" and he has to agree. (I don't get a lot of grief from female EE's, and their boards tend to be better from the outset.)

Glad you figured it out. And - you provided oscope pictures. Rare for posts about such problems.

Hardware engineer developed the boards.

>> Glad you figured it out                                              All the information and clues provided in this thread was extremely helpful.

If you had a 50% failure rate for 4 boards, y'all need to find a better board house - just say'n....

We are here to help...