The particular part of mkheader compilation with -O0 was introduced by dkg for cross build support.
I believe that -O<number> (where <number> is not zero) is common but -O<something-other> is dependent.
Requesting non-optimization by -O0 seems GCC specific.
(I grep-ped autoconf-archive and observed the use cases of -O0.)

Considering the concrete use case(s), it is more rational to support listing by capability.

In 2.2.18, this fix is not included. (partial fix was reverted)

Applied and pushed.

The last fix was in 3681ee7dc1e9d8c94fdb046d7be0bbcfeba1cfe9, on 2017-07-05.
And it is included from the release of 2.1.22.

My analysis is that it's not a race condition but... it's about secure memory.
It is true that we have a race condition between putting an entry to cache after pinentry interaction _and_ next examining cache to invoke pinentry. But for this test case, the gpg process of unlock the key (and cache the passphrase) is finished before running the run-threaded command.

I believe the problem was fixed in the master of pinentry with newer gpg-error-config and libassuan-config which support cross build better.

Confirmed that the support of --no-global-grab doesn't work well.

My message above is: The reported issue of ^C was fixed in pinentry-tty and GnuPG in master branch. Please test that fixes.

Please note that pinentry-tty/curses is a kind of emulation of CLI user interface, it's not the real one (I'm going to explain in the next paragraph).
It is, by any means, not robust, as users would expect, from the implementation's view. It only works specific simple use cases (while I do my best to stabilize it in master branch of GnuPG).