I understand user frustration, but I think it’s sealioning to vent in every sync related thread on the lack of documentation. Make it a dedicated thread then.
anyway, here's what I know on eDrive
deletions will not propagate from either side - that code got neutered.
The sync mechanism is “additive” from and to both sides, but with “a memory of files” device-side.
Device-side record keeping of ETag (a hash basically) and last-modified-date are used to decide what side wins on same-name but ETag difference: the more current file wins. There’s some risk to this (independent edits to both files outside a sync window or wrong modified timestamps on the remote after a backup restore).
If you get rid of the tallied database app side (eDrive app storage reset or re-adding account): it will reupload or redownload files it tracked their state of before (I think that is what you experience). That is: device-side deleted files by user choice but formerly uploaded will be downloaded to the device again.
Since the outage there is code in v2.9 that will do the described eDrive reset itself and force a file push from the device to cloud and re-establish the sync. Can’t say if the users opening these threads are below v2.9 or if the code didn’t land yet. I use eDrive only minimally to know from experience.
Notes and eDrive are fundamentally different apps and mechanisms (API vs WebDAV). Android itself schedules what the App requests.
Inside eDrive there’s a periodic/full scan and a file observer service. They use the same functions internally when comparing remote to device local service. ScanWorker is said to be a third mechanism with the same properties in behaviour - haven’t read that code yet.
There’s at least a 30min interval to the periodic one, fullscan triggers on boot and I think on plugging a charging cable. They all need an unmetered network to transfer files.