When attaching a file with the same name in a comment, Jira renames the file, but not the reference to it

Issue Summary

There is a mechanism within the old issue view of Jira Cloud that when you upload an attachment, if that issue already has another file attached to it by the exact same name, Jira will rename that new file. If abc.txt already exists, then second such file by that name Jira renames to abc-1.txt (or more recently abc (331ea118-8e2e-4124-ab56-765f307deabf).txt) as it is accepted from the browser and before attachment is complete.

The problem here is that when doing this when adding a new comment, the mark down seen in the new unsaved comment does not reference the correct file that the user selected, but rather the original file on the issue.

Steps to Reproduce

1. Attach a file to a Jira issue, example filename such as abc.txt
2. Use the old issue view ... > See Old View (or by going to append ?oldIssueView=true to the URL)
3. Make some change to the file in question (abc.txt) on your local computer, but then save it locally with the same filename
4. On the same Jira issue (in the old view), now create a comment, In that comment, use the toolbar to click the paperclip icon to attach a file, but instead of choosing the existing attachment, choose Browse and then on your local system select the new file by the same name
5. Note that Jira will rename the newly attached file in order to attach it to the issue. But the reference made in the comment does not change accordingly.

Expected Results

We expect that the still unsaved comment will be referencing abc-1.txt, because that is the same logical file that the end user selected

Actual Results

Instead, the unsaved comment is making reference back to the first attachment (abc.txt). This in turn is very unexpected to the end user that may have never even looked to see what that original file was. Since Jira is renaming the attachment automatically, then it should also automatically update the selected file reference before the user saves the comment.

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available