Before I dive in and look at making changes, it would be helpful to understand the thinking behind the approach, and the intent of how it should work, particularly in regard to the points mentioned above, but also in any other related regard. I do have a local change for writing only changed memories, but I'd like to have the big picture before going any further.
It was a bit of an experiment, an attempt to rethink the split and maybe close the gap on the behavioral differences. I was thinking these would effectively use csv as their backing store for saving (which right now is an export, yet another step those users). As you note, keeping track of the memories we need to upload in a single session would be easy, but unless we persist that, we'll have to (slowly) upload the whole thing if we have closed and re-opened it. Radio settings are another thing that we couldn't perisist (in CSV at least) and which would have to behave differently if the tab was closed and the serial link to the radio lost.
Windows also has specific requirements about how all the GUI updates have to happen from the same thread, which is one reason for current radiothread stuff in the main branch, and minimizing what gets done where (i.e. a single simulated clone) helps address that problem.
All that said, I wasn't overly thrilled with the experiment, because while it seems to be simpler and more uniform from a UX perspective, the above issues, of course, make it not as straightforward. So I dunno what the best plan is, TBH.
--Dan