CHIRP

I just dug out my ID-880 to test this. It looks like from your log you're using the speaker jack method, so I connected it with my OEM OPC-478 cable and an FTDI USB-to-serial adapter to my Windows 10 box. Download, upload, download, upload all worked properly back to back.

What kind of cable and USB adapter are you using?

The log (both the first one and this one you just uploaded) shows that the radio does indeed respond to the second upload request. CHIRP does several back-and-forths with the radio, and then it starts sending the image, but the radio never responds with the end frame. Are you sure the radio's display never goes into CL IN?

Yes, the radio does not go into CL IN. CHIRP_NEXT shows the upload progress bar and fails after appearing to go through a normal upload by the speed of the progress bar.

Okay, I feel pretty confident that something is up with the radio if that's the case. The radio should go into CL IN mode as soon as it responds to our request to send the image (before we do), which it does. I think that if you were able to download, close, upload-fail, upload-succeed that means that it's not CHIRP-next specific and it's the radio being flaky. The ICF (Icom Clone Format) module for the last chirp-daily build is almost identical to what is in chirp-next currently, for this type of radio.

Have you tried hard-resetting the radio to see if it improves its behavior? The radios do have limited write cycles on their EEPROMs, after which they start to get really flaky in that they take some writes and not others. It takes a LOT of writes, but it does happen, so it's possible that this radio is starting to suffer.