Please dont take this as a criticism of your methods or an accusation that this was your fault but there are some ways you can 1) protect your data and 2) collect more information for troubleshooting to see what really went wrong here.
1) When handling important data or when managing it with new unfamiliar new methods, or when managing it on Android devices, or with data that is not already rigorously backed up; it may be best to copy material then delete the source. This does leave more responsibility and work on the user than automated processes but that is to the point of protecting data especially until the methods are sorted out and deemed reliable.
2) In MiX, when items are selected for a move operation they disappear from the UI (perhaps to avoid application of conflicting actions - eg attempting to copy a file that was moved from the source location) but when the job is cancelled they should reappear. I would hope that the same would occur for a job that ran out of space.
So, in your case something seems to have disrupted the protection of the queued files, or flagged them as moved even though they were not moved, or something else. To the point of your request perhaps there could be a way to check available space and warn user before the copy process starts so that the job may be cancellated before the queue gets scrambled.
In relation to Point 2, how can I help you to understand and resolve this bug? Would the reproduction of the issue and then take a debug log work?