To summarize, I show both local and remote folder contents.
Re-create the RCLONE_TEST, rclone bisync --resync,
show the folder contents again, created the t7.txt locally,
then rclone bisync, then it erased my remote folder.
https://pastebin.com/XPYqBg5P
And I see it exists on the remote side at the end:
maiko@maiko-rpi:/media/FILES/mkdrive$ rclone ls oned:notvault
0 t8.txt
but I don't see anything in the middle showing a transfer of t8.txt from local to remote.
Is it possible that you have another instance of rclone syncing the same directory at the same time? Perhaps your previous --delete-excluded command was still running from a cron job in the background while you did your test? Because otherwise, there should be a log here showing how t8.txt got transferred.
Further, the behavior here is consistent with what I'd expect for --delete-excluded. The one file that needed to be copied ( t8.txt) is the only one that exists at the end -- everything else was excluded, and thus deleted. (Which there is also no log for, and there should have been.)
If you don't think there could have been a competing process, let's simplify and try to reproduce this with a more minimal test, to eliminate some red herrings. Create a new test directory that you haven't used before. Use only full absolute paths for your commands instead of cd with relative paths. Be consistent about using or omitting the trailing slash. And use rclone touch and rclone lsl instead of the default touch and ls, so we can see exactly what rclone sees. Omit --links for now. If you can still reproduce the issue, we'll know those variables were irrelevant. If not, we can try adding them back one at a time to see which one is responsible.