Can't Upload via USB but ISP works on UNO R3

I'm stuck with uploading to the subject on a new UNO R3 board. The ISP works fine and I have uploaded and verified new boot loader into the 328P as well as new code into the AT16U.
The Board ID returns what seems to be the correct board ID.
So my question is: Where does the Board ID come from? If the 16U had a problem with hardware drivers then I should't get a reply.
The Tx led never seems to blink but Rx is active.
I tried a loop back test with no success.

I have this verbose from the upload which gets stuck then dies after 10 attempts.

Verbose Bootloader text.txt (2.46 KB)

You do realize that if you upload a program via ISP, it erases the bootloader, right? You need to "burn bootloader" again to put the bootloader back after uploading a sketch via ISP.

I do. I think the USB hardware is working, although I would like to see some activity on the TX led. I have a feeling something is amiss between the two chips, but then, where does the Board ID information come from? The 328P chip?
The .h from the sketch export has a bootloader variation which I used.

Board ID comes from the 16u2, unless you mean the signature (that comes from the bootloader)

How does the 16UA know which chip it is connected to?

Looks to me like the USB serial connectivity is OK on the board if the 16UA is able to send and receive.

What could prevent the 328P from talking to the 16AU?

I looked at the 328P fuse data and don't see anything there that would interfere with communication.

Could you elaborate a bit more wrt the term "signature".

This is the Board ID I see:
BN: Arduino/Genuino Uno
VID: 0x2341
PID: 0x0001
SN: 8573531323335180F112

Edit: I have the schematic and will check the Tx Rx signals out of the 328P to the 16UA; there are a couple of series resistors in those lines maybe one is dislodged. I see they go to P0 and P1.

Thanks for the response

Problem solved!
The board via on PD0 to the 16AU was bad. Repaired with a thu nail hole jumper made from 30AWG wirewrap and soldered.
Thanks for the feedback as that helped localize the issue.

The 16u2 doesn't know what chip it is connected to. The information that it gives is hardcoded and the firmware uploaded to an uno and to a mega is different.