The problem is that gpgme-w32spawn.exe uses DETACHED_PROCESS which means that the newly created process does not inherit the console of the parent process.

As I understand it: The parent process started by gpgme (in that case gpgme-w32spawn) has no console as it was started without DETACHED_PROCESS and inhertis the "no console" from the GUI Application. But the second child created by gpgme-w32-spawn does not inherit the "no console" and gets a new console because it is created with the DETACHED flag. I don't really see a reason for that except maybe debugging. But that flag was there from the start so I think there might be a regression risk to change this now. I also don't understand why this does not always happen for gpg calls but only for some. Is w32-spawn maybe not used for the engine-gpg calls?

Doc for the process flags:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms684863(v=vs.85).aspx

This removes the console windows:

diff --git a/src/gpgme-w32spawn.c b/src/gpgme-w32spawn.c
index 003b9b03..d86c8508 100644
--- a/src/gpgme-w32spawn.c
+++ b/src/gpgme-w32spawn.c
@@ -205,7 +205,6 @@ my_spawn (char **argv, struct spawn_fd_item_s *fd_list, unsigned int flags)
     }
 
   cr_flags |= CREATE_SUSPENDED;
-  cr_flags |= DETACHED_PROCESS;
   if (!CreateProcessA (argv[0],
                       arg_string,
                       &sec_attr,     /* process security attributes */

I need to look at the code. I remember that we used to flag executables as GUI applications so that they do not show the console at all.

The overhead of querying the capabilities of the components (--gpgconf-list) is indeed annoying. However, what they return is not only static information but the actual configuration (e.g. default algorithm) as described by the components config file. So I don't see a quick fix for this and would perfer to rework the system in 2.3 - or just live with it and get rid of the flicker.

The overhead of the start should be reduced by kleopatra as it uses a static c++ object that is only read once. Yes that might contain stale values but we don't expect users to meddle with config files while they have kleopatra open to edit the config.
Similar for GpgOL. Stuff like compliance is only queried once, (maybe twice?) during startup.

I'm using a gpgme-w32spawn helper in my development environment with the above change. So far I have not seen a problem so I'm tempted to just change it.

*cough* That change made it into Gpg4win 3.0.2 *cough*

The assuan_pipe_connect function is called with bit 7 set for example to start pinentry or scdaemon:

Bit 7: If set and there is a need to start the server it will be
       started as a background process.  This flag is useful under
       W32 systems, so that no new console is created and pops up a
       console window when starting the server

if that bit is set DETACH_PROCESS is used. The reason why we used this for pinentry is clear, we didn't want to pop up an an additional console. I think we have some reversed logic here, DETACHED_PROCESS _sounds_ like it creates a detached process without any console and somehow this worked (but may be more due to the console/gui flag set in the binary).

I checked the mingw runtime and did not found any allocation of a new console. Thus I don't understand why a console pops up when gpgconf is used. gpgconf spawns gpg et. al to read its options and it does this without using DETACHED_PROCESS. Thus all these subprocesses inherit the parents console - which is for gpgme started process no console (due to DETACHED_PROCESS used in gpgme_w32spwn). For a GUI application like Kleopatra which has no console, the use use DETACHED_PROCESS sould not make a difference because there is no console to inherit. Andre's test however show that it makes a difference.

Thus I'll apply this patch for the next gpgme release even that we do not understand the how the gears interact.