Reality Exists

Oh, yes, I did that and the test passes and reports the correct number of files (32466766). It takes about 2 minutes just to open the file, peaking at ~12.3 GB RAM used. The test itself takes about 15 minutes on my machine (not the same machine where the archive was created).

Well, it worked! However, the file count in the dialog at the end is slightly lower than the total number of files compressed: 32466178/32466766. I opened the resulting .7z file and 7-zip confirms that there are 32466766 in it, so that seems like another (minor) issue with the progress dialog.

Ah OK, thanks for saving me 4 days. :) I'll try again with Ultra, but with an even bigger pagefile. (Yes, it's very slow, but it's very slow even before using swap space.)

Well, it did fail near the end, at 98%, with "The system cannot allocate the required amount of memory". This happened during the night, so I don't know the exact amount of RAM it was using then, but it was up to ~30 GB before, even though the "Create archive" dialog estimated something like 2.5GB for compression (I chose Ultra, LZMA2). Trying again now with Maximum, will let you know in 4 days or so. :)

I'm not sure, since it's a virtual machine and I have no access to the physical machine, but I suspect it's probably some kind of network storage, rather than a real local disk.

Estimated "remaining time" is off significantly due to scanning time with very many files

I tested a little more and found that this happens only when dragging an item to SUB-FOLDER of the current (source) folder. When dragging to any other folder I get the expected behaviour. Re #3 - I should probably have said "focused" instead of "selected". The Windows Explorer behaviour when deleting or moving a file is to focus on, but not select, the next item and KeePass is consistent with that (when deleting and when dragging to a folder that is not a sub-folder). So basically the behaviour when...

List position and secondary sort order is lost after dragging an item to a folder