The "Reliability History" says (in Chinese):

异常代码: c0000005
异常偏移: 0002b6c0

The error code c0000005 is something like SEGV on POSIX, I guess.
It occurred at the address 0002b6c0.

In general, I agree. But, given that the whole file is Windows-only and highly Windows-specific (dealing with the Windows registry), does it make sense in this case?

For portability reasons it would be better to define F_OK if is is not defined.

For SPR532, we need following.

I'm pretty sure what happens, but apparently I haven't been able to explain it clear enough. To reproduce you can do like this:

1. On an old machine having GnuPG version 1, e.g. Red Hat Enterprise 5:
   1. gpg --homedir $PWD/homedir --gen-key
   2. tar cf homedir.tar homedir/pubring.gpg homedir/secring.gpg
2. On a more modern machine having GnuPG version 2, e.g. Red Hat Enterprise 8:
   1. tar xf homedir.tar
   2. touch apa bepa
   3. gpg --homedir $PWD/homedir --sign apa # Does the migration, and signs "apa"
   4. mv homedir homedir.moved # Don't remove, just move
   5. tar xf homedir.tar
   6. gpg --homedir $PWD/homedir --sign bepa # This will fail as explaine in point 5 of the initial description

That is just one bit different - Shouldn't we better have a wrapper as we used to do for other things?

The inotify thing is only used to detect a deleted homedir and stop the agent. AFAIU your problem is that a migration is triggered again. The migration status is a file ~/.gnupg/.gpg-v21-migrated - are you sure that you have extracted it again?

Applying following SOS-handling, the key can be handled.

diff --git a/g10/parse-packet.c b/g10/parse-packet.c
index 9cb254e24..be7fc6d67 100644
--- a/g10/parse-packet.c
+++ b/g10/parse-packet.c
@@ -188,6 +188,76 @@ mpi_read (iobuf_t inp, unsigned int *ret_nread, int secure)
 }

Note that there is no problem for encrypted key, because it is handled by opaque MPI.

The whole TOFU stuff hash not yet been fully translated because there are conceptional problems with the way the code works.