I removed gnupg from the %AppData% directory and restarted Kleopatra, but I am running into the same permissions issue.

Have you tried on the command line: "gpg --gen-key" ? Maybe this gives more helpful debug output. But in the case of "permission denied" this really sounds like a local setup issue as there are also no other reports related to this. Still I'll add the saveguard to make the check in kleo more explicit.

Guys, no offense, but you screwed things up a lot.
You should have put some warning within installer 3.1.15 when it updates files, or at least make an error message more verbose.
Right now it is totally not obvious what to do (move from where to where{F2234144}) except for rolling back to previous version of Kleopatra.
For example, I a PC user with administrator account only (and it will remain forever), so?

Sorry, but we are a security software. If you give any application that you run on your system root privileges then that is not a secure behavior. This kind of stuff has been deprecated with Windows Vista. Yes we changed the error to a warning as it was too zealous. I agree. It is not our place to educate users. But users should change your operating procedures. You should not handle protection worthy data on a system without privilege seperation.

And honestly, some people complaining on reddit you find for everything, we have over 100k downloads a month.

It seems you still don’t get what was wrong about this issue. There is no opposition to separation of roles (which is, however, a rather complex topic that involves determining a threat model and only then defining what is right or even mentoring what one must) — this is about unconcerned communication, the very way error message is written, implying that the rest steps are widely known, could be guessed or found on your own. For example, I have 20+ years of experience as a beta tester and didn’t get what was required from me to do to make Kleopatra work again, hence the outbreak. To have an example of good communication, try Veracrypt. Bottom line: software is meant to be a solution, not just pieces of code displaying windows and messing with files.

This is a bit more complex for us. I have often noticed the pattern of Windows users that if something does not work as expected they click "Run as Administrator". When they do that once with our software our backend software gnupg is also started with elevated privileges, it might create lock files with elevated permissions it might create data files. For example a user then generates a new key, but already had some keys the public key will be placed in the existing keyring and the permissions will not be changed. But the new key files created will be created with elevated privileges. Then the user runs Kleopatra again as normal user and reports bugs because he cannot access his newly created key files.

That is what we mean by "breaks the GnuPG directory" and that was the intention behind this change which we now have tuned down to a warning. I really was unaware that running a full desktop with administrative privileges was at all common or even possible in modern windows. I think at least for Windows 10 you cannot do that anymore without fiddling with the running services.

Please let us turn this into a fatal error again. I had too many support cases where Kleo was actually run with Admin rights and messed up the permissions. To help with development issues and for the sake of some blockheads introduce an envvar to bypass the error.