As it is now, the recent projects list contains a unique list of projects. If you try to open a copy of a project, say from a backup, the list will replace the old entry with the new path, because both projects have the same internal ID.
The reason it does this in the first place is so you don't get duplicate entries if you simply moved a project. However, precisely in the backup case, you may actually want both copies open to transfer content. While this is possible, by ignoring the recent project list and just browsing for the projects, it isn't ideal.
A solution here may be to add additional meta data to the backups so that novelWriter knows it is a backup, or possibly just ask what to do when a duplicate ID is detected.
As it is now, the recent projects list contains a unique list of projects. If you try to open a copy of a project, say from a backup, the list will replace the old entry with the new path, because both projects have the same internal ID.
The reason it does this in the first place is so you don't get duplicate entries if you simply moved a project. However, precisely in the backup case, you may actually want both copies open to transfer content. While this is possible, by ignoring the recent project list and just browsing for the projects, it isn't ideal.
A solution here may be to add additional meta data to the backups so that novelWriter knows it is a backup, or possibly just ask what to do when a duplicate ID is detected.