Lawrence summed it up fairly correctly (thank you).
The point is that it’s the strategy in AxCrypt 1 that *is* broken. Since it can’t determine the correct situation in every case every time, it just doesn’t work. This was a learning experience over several years in AxCrypt 1.
We’re trying to make AxCrypt 2 more robust in many ways. In this case we tried to use the very simple rule: If the launch starts a new process, we assume that when that process exits – the file is no longer in use. The relaying launcher like you have breaks that strategy.
So, the end result is we’ll probably have to give up trying to be smart. Because if we try to patch this case by being smart (like, oh the launched process launched another process as a child, then we’ll wait for the child or something like that) we’ll just be outsmarted again by some other app’s weird behavior.
You can follow the issue here: https://bitbucket.org/axantum/axcrypt-net/issues/211/file-association-with-launcher-instead-of .