This is similar to #5149 where re-uploading an existing content artifact would overwrite the file in storage, updating its Last-Modified time. That was fixed in #5196 for the content upload path.
The same problem exists when creating a publication for a repository version that has already been published. The metadata files (e.g. repodata/filelists.xml.gz) are identical to the previous publication with the same hash but still get re-uploaded to storage. On backends like Azure Blob Storage this updates the Last-Modified time and ETag, which causes the same CDN caching issues as described in #5149.