The problem being seen is likely exactly what was warned against here in previous question/answer…
So Windows machine has never seen backup 2, sees the additional files from backup 2 as extra, and “fixes” the inconsistency by making the remote look like what it knows about, so there ends backup 2. Direct restore won’t see backup 2 either because the files from backup 2 are no longer on the remote.
Linux machine DB tells it it has two backups, and it expects remote files (it knows it changed nothing). Surprise comes when it tries to do something, checks remote files in advance, finds backup 2 deleted.
Backup services such as CrashPlan presumably have server-side databases that allow things like an adoption process where a new computer adopts backup computer identity used by previous computer.
Computer identities: How they work
Duplicati cannot rely on much from remote, certainly not an assumption of specific API or DB to help it. Remote is assumed to have very basic capabilities such as file put, get, list, delete, and a folder create. This leaves Duplicati largely on its own to query its local DB and periodically verify the remote matches.
EDIT:
Duplicati silently, permanently deleted backup from google drive - two-machine use case #3845
has some other thoughts about ways that the problem might be tackled, but the collaboration goal there really isn’t a good fit for a backup program like Duplicati. I suspect CrashPlan won’t need a refresh to do another download at the other-system-destination, but Duplicati (for the moment anyway) refreshes the wrong way, “refreshing” the remote to match the local. I don’t know if repair rewrite will allow DB refresh.