Thans for reporting!

First, have you cheked AutoClean?

That appears in May onwards versions of devel branch. It shoud keep the log_changes clean, but also causes manual work If you keep (one or more) online log off for a while
and then return using it. Then you need to make it up to date manually.

So far I have not noticed LoTW/eQSL updates causing reuploads if checkbox is cheked. On the other hand I have worked so little qsos that I may have missed the bug.

Three time upload is interesting. I have to watch this too.

With HamQTH I have noticed problem that was caused by the server not responding. But only once.

"Could not delete original qso data" should refer to Update action. If original qso data can not be deleted and upload is not stopped then next comes same qso's insert.
That means duplicate at Online log's side and that is not good thing (possibly rejected by server).
Program should then jump over an continue with totally different qso.

The error detecting is very complicated task as every online log has different way to report errors. Then errors have two (at least) categories. Problem can be in network or from address/command. 
If all those goes ok then respond is usually "200", otherwise some of "40X" numbers.
But if you get "200" that does not make success. It tells just that connection has been made ok. Then comes the data handling errors that send different kind of text messages.
And all differs.

Online logs are big mess. Devil's inverntion. Why they could not agree a standard API where basic functions and responses would be similar for all online logs?
Should not be so hard.

Bugs are hard to detect. You should have a simulator programs of all online logs but then you shoud have full information of all possible responses of online log API.
To peek what should happen at Cqrlog side you can look at the database side. It can be done with QSOList/Filter/SQL console, but better way is to use command console that gives larger view specially with hires, or several, monitors.

With "save log data to local machine" you can open console mysql after Cqrlog has started with:
mysql -S ~/.config/cqrlog/database/sock

Once connected to database select log using same three digit number as the opened log has:
use cqrlog004

Then view tables related to online logs:
select * from log_changes;select * from upload_status;

And you see two tables. bigger one, log_changes shows what commands should be done with qsos and smaller one upload_status shows what has been done for every single log.
"Upload_status/id_log_changes" number refers to "log_changes/id" number meaning that this "id" line was last one processed by "upload_status/logname" online log.
So it is very easy to see what will happen on next time uploading starts. And also see why something (three same uploads) happened (if you keep "AutoClean" checkbox unchecked!).

After adding QRZLog there is also one addition to database tables to keep record of uploaded QSO serial numbers that QRZLog needs for referring a QSO to delete. (that is again totally different from other online logs way to do this).
I made a new table for that called "id_store"

Every qso in log has unique "id_cqrlog_main" and corresponding "qrz_logid" appears when qso is uploaded ok.
When qso is deleted from log "qrz_logid" is used to delete it from QRZLog. After successfull delete the line form table "id_store" is removed. There is also cleanup routine that removes all lines from "id_store" that do not have corresponding "id_cqrlog_main" line in log.

Then the prevent log changes to affect online logs.
There are three triggers in database that are handled by MariaDB without any action  of Cqrlog. Every time cqrlog adds, changes or deletes qso from log table those triggers are fired. Either before table is changed or after table has changed. Triggers do operation that afftects elsewhere. In cqrlog's case it affects (adds lines) to "log_changes" table that drives online log upload actions.

Previously disabling online log upload actions was done by deleting triggers for a while when operation that should not make changes to uploading was done. After that triggers were recreated.
That is very bad way and should not be used by a program. Only database administrator should do that if some maintenance requires trigger touching.

How ever there is no "switch" to turn trigger on and off without deleting/recreating it. There is a workaround for this using a conditional trigger. Usually trigger is looking a session variable and if it exist or not and run it's operation by that. How ever session variable is hard to implement to Cqrlog as there are so many different database connection sessions.
That is why I created another way to make conditional triggers. There is small table carrying only log database version number called "db_version". I added one column "stop_trigs".

"stop_trigs" should get value "1" when changes to log should not affect to online logs. With no value or "0" triggers will work normally.

NOTE: upgrading of old log to db_version 20 should create table "id_store", column "stop_trigs" to "db_version" table, create new triggers and add line "qrzlog" to "upload_status" table.
If some of them fails the the database upgrade at first opening of log has a bug. (found some during tests and they should now be ok,. But who knows...)
Also new log creation should bring those to clean new log.

You can see database triggers with command:
show triggers;
But it gives very large output. I can not see it full even when using whole wide of two monitors. Then main thing is that there are three triggers "cqrlog_main_ai"  "cqrlog_main_bu"  and "cqrlog_main_bd". And all those have "IF NOT EXISTS ... END IF" to indicate they are "new version" triggers.
Name last part meanings:
_ai = trigger After Insert
_bu= trigger Before Update
_bd= trigger Before Delete

As you see the online logs are very compilcated task.
I am very pleased to have bug reports because I can not find them all alone.
How ever it is very important to know what and how it happened and what was done before that and what were the selections in preferences.

if you do a change to log, without immediate upload, then you have time to peek the log_changes and upload_status tables to see what they look like, perhaps save a screen copy, and then do the upload by manual selection of one log, or upload all log changes.

Finally some words of QSOList/OnlineLogs:
"Mark EVERY qso to uploaded to ALL logs" that will clean the "log_changes" table but keep the "id" number as was and set the same number to all lognames at "upload_status" table
"Clean table log_chages" will do the same but sets "id" to "1" overall. (actually this is not very important any more. It was "remove all upload triggers" when it also cleaned and recreated the database triggers)

Please inform me about bugs. The more you can give information of situation when bug happened, less work it is for me to find the reason.