Additionally, does your answer imply that when I ssh into remote, no gpg logs on remote should be produced if everything is executed correctly?

I see. How should I prepare environment instead? With local it is clear, but with remote it isn't. I also use remote as a normal machine with yubikey plugged directly into it most of the time, as it is a desktop at home. Local is a laptop that I use when I'm not at home. So, let's say I have a fresh reboot of remote and use it a bit with yubikey. So, it has gpg-agent started with its own socket there. Now I want to ssh into remote. If I understand correctly, for correct functionality I need to kill gpg-agent on remote first, otherwise agent forwarding will misbehave? Then, after I'm done with ssh and get back to remote (physically), how do I "recover" from ssh and re-launch gpg agent normally again? Since you say that killing it will send instruction to kill it on local machine, what should be done instead?

I didn't run gpg-agent or scdaemon on remote manually. If that happened -- it probably happened as a result of ssh'ing into it and spawning a zsh shell, which executed the section that I mark as "Environment (per shell)" above. I do this kind of "preparation" (stop gpg, clean up logs to collect only relevant logs on problem demonstration) to make the problem description as minimal as possible. And I post all relevant produced logs to make the problem description as complete as possible. Sorry if this is confusing, I don't really know what I'm doing but I want to make a bug report that can be acted upon.

Thank you for the response.

In the meantime you can use [0]. I have tested with ssh key on yubikey and AuthenticationMethods publickey, win32-ssh (or ssh-portable, which is the new repository name) correctly works with gpg and pinentry is called. Despite it being called wsl, wsl environment is not required.