If I open a large RAR archive in the destination pane by pressing the enter key, a progress dialog with an abort button appears as pane content. If I press the tab key to switch over to the source pane I can't open folders by pressing the enter key anymore. After the task in the destination pane is finished everythin is fine again.
I just noticed that the intermediately pressed keys are queued and the associated actions are lazily performed when the task in the destination pane is finished. It seems that the input event handling is suspended unintentionally as long as the destination pane is busy.
Leo, can you reproduce this?
Directory changes within the same window are queued up if one is already pending.
Normally you wouldn't notice it as changing directory is normally very quick, but large RAR archives with lots of files take a long time to open due to an unfortunate choice of how RAR is designed (the entire archive has to be scanned).
If you can use any other type of archive except RAR (and things like .tar.gz where the whole archive has to be processed just to get a file listing), you shouldn't see the problem anymore. But if you are stuck with large RAR archives then I am not sure if we can fix this, as I would be quite worried about any changes to the way it works causing problems elsewhere.
(Note that it's not waiting for the directory listing to be read, just for the "change directory" request to finish. So this should not affect large/slow device and network-share directories. But with archives the "change directory" request means opening the archive to make sure it is valid etc. and in turn the archive libraries tend to get a file listing as soon as the archive is opened, so Opus is waiting for the file listing to complete even though it does not need it at that stage. Opus will then ask for the file listing, after releasing the queue of any other directory changes, and the archive library will return a cached list of what's in the archive.)
Isn't it possible to interpret the opening of an archive as directory change but the actual loading of the archive content as directory listing (which obviously may fail due to an corrupted archive -> similar as a network folder may fail due to a connection loss).
In fact all of our flight data archives are created as RAR archives each having 10-20 GB placed on a slow network drive.
To be honest it's a pain to open them due to the missing TOC in the RAR format. But the pain is doubled if we can't use DOpus to browse them. 
It is possible but it's also the type of change which would be very complicated and is likely to introduce bugs in other places, so I am reluctant to do it.
If it affected a lot of situations or a commonly-arising situation then the risk and time would be justified, but when it's just for huge RAR files I am not sure that it is... RAR isn't a great file format for storing large archives with lots of files (vs large archives with only a few large files) and thus people tend to avoid it and not see this problem very often. (Whatever we do, you'll still have to wait for the RAR archive to open before you can do anything with it. We can't do anything about that.)
The real problem is with the RAR format taking so long to open files, IMO. While it's possible for us to change the way Opus opens RARs, it's also likely to cause headaches/bugs and consume time we could put into other work if we do. Equally, it's possible for you to switch to an archive format like 7z (combines good compression with fast opening (TOC)) or lobby for an improvement to the RAR format so the problem doesn't happen in the first place. Presumably you have reasons not to want to do those things even though they are possible, as do we. 
In fact the format decision was made by other people many years in the past.
Personally I do not like the user interface of the 7z tool for Windows.
Anyway I will try 7z for home use to get a feeling and I will contact Eugene Roshal in parallel concerning the TOC problem.
You don't have to use the 7-Zip UI. Opus and WinRAR can both create 7z archives, for example.
Opus I know about that but WinRAR can only create ZIP files if I remember correctly.
Anyway 7z integration in Opus is native, thus it is very convenient.
Ah yes, you are right. WinRAR can extract 7z but can only create RAR and Zip. My confusion.
I just got an answer from Eugene. He wrote that an optional TOC is something they are thinking about to increase the opening performance for large archives.
By the way, I just made a simple benchmark on my system:
Compressing 1 GB Derby database using 7z (DOpus):
539 MB taking 3:01 minutes (best compression)
Compressing 1 GB Derby database using WinRAR:
578 MB taking 0:28 minutes (best compression)
So 7z's best compression reduces the file size more while taking longer. Not really a fair comparison. 
Make sure solid compression is off in 7z (it's off by default in RAR, and you wouldn't want it on for archives you regularly use interactively), and try a lower compression setting (e.g. one that results in a similar archive size to RAR).
Compressing 1 GB Derby databsase using 7z (DOpus):
595 MB taking 1:27 min (fastest compression / non-solid)
The performance gain of WinRAR results from its great multithreading on my system.
7z only uses 2 cores (~20% CPU load) whereas WinRAR v4.2 takes 7-8 cores (~90% CPU load).
Just interesting for me to get a feeling about that. Haven't had tried that for months.
Compressing 1 GB Derby database usig WinRAR 4.20:
610 MB taking 0:12 min (fastest compression / non-solid)
But 12 seconds to read + compress 1 GB and write 610 MB. That's impressive! Good to know for creating quick backups when time is trump. Anyway I will go with 7z for a time, because the compression is better.
Sorry for off-topic!
As fastest compression I'm surprised the CPU or threading matters a great deal, vs the speed of the disk/cache. Who knows, though. There's a lot of factors at work.