Nuances like that matter if you consider issue tracker as a means to communicate the status of problems that were reported in the project. For that purpose, it makes sense to invest some effort into ensuring that bug report is easy to read and understand.
This situation gets much less confusing if you look at it from a perspective of a tester. If your team doesn't have a tester, imagine one (or better yet, hire one 1, 2, 3).
Okay, so there was a bug once upon a time, tester can reproduce it using older releases of your application (side note in unlikely case that you don't keep copies of older releases, then you've got much much harder problems in your team than obsolete bugs). Tester can see it and can tell what's wrong, what is it that makes it a bug.
Now you say, "layout has already changed and it is no longer relevant" - the high-brow no longer relevant turns in tester mind into much simpler statement: the problem has gone.
- It is important to note here that professional tester should be comfortable thinking of the system as a black box. From that perspective, it doesn't matter much how exactly it happened that problem has gone, it could be layout change or black magic or total redesign, or concrete code change, whatever.
From black box perspective, your situation is pretty simple. There was a problem, it's still reproducible in older release, now you claim that newer release has no such problem anymore. For a tester, this boils down to a claim that bug is fixed and, respectively, to the need to verify whether the claim is true.
Professional tester would take your older release, look at how problem is present there, then take newer release and check if it is gone or still there.
From above, the most accurate way to handle bugs like you describe, would be to close these as resolved, fixed. Of course it wouldn't hurt if you clarify in the comments that the fix occurred as an unintended side effect of layout change.
One of customized JIRAs I used to work with in a past project had resolution "Fixed By Design" to communicate rather profound changes having lots of consequences, some intentional, some not. For case like you describe, that could be also considered instead of plain "Fixed", since it hints ticket reader on that it's more of a side effect rather than intentional code change.