With VS-Desktop-3.1.90.300-Beta I do not any more see more than one dirmngr for the test user who is not in the windows test-domain.
But I still see 2 processes for the domain user. Which is less than before. Task manager for all users:

It looks as if it could be one dirmngr.exe per user and per path given in the call to it. One with slashes and one with multiple backslashes.
Do we have different calls to dirmngr.exe where the form how the path is given differs? At least on windows?
The Domain user was the only one of the two who had a working keyserver configured.

One proces per user is normal but the two for ebo-ad are strange. Especially the one with the multiple backslashes. I wonder where that came from. Can you try to find this out? e.g. have taskmanager open while you repeat your test and check when it comes up.

further improvement after the 3.2 release

When I do a search which is found on the keyserver, only the one without the multiple backslashes comes up, this seems to be started via gpgme call.
When starting again without a dirmngr and searching for a key which can only be found via WKD both entries appear in the taskmanager after only one search. The same is true if the key can be found in neither place. It seems the backslashes are associated with WKD and start is probably via gpgconf.

I guess that the second instance is started by gpgsm_new (engine-gpgsm.c) via assuan_pipe_connect.

Double backslash quoting is the culprit. For WKD requests the GPGMe QT code makes sure that the dirmngr has been started. This is done by running gpgconf --homedir FOO --launch dirmngr. gpgconf returns the homedir with backslashes on Windows to be be nice to ppl who wonder when they notice (legal) forward slashes on Windowns. Now when the spawn function along with its helper is called, it needs to quote the backslashes. But somewhere on the way back one de-quoting is missing and thus gpg sees double backslashes. That is in general not a problem but when checking whether this is the standard home directory, this does not match and gpg puts the socket into a subdirectory. In turn another dirmngr is started for the WKD purpose.

The fix should go into gpgme to spawn dirmngr with a proper home directory (i.e with forward slashes). Further we can detect double quoting when set parse the --homedir option and fix this too in most cases. Bonus points for actually figuring out why quoting and unquoting does not work as expected.

I think the double backslash quoting happens because _gpgme_io_spawn quotes the backslashes and calls gpgme-w32spawn and then gpgme-w32spawn quotes the backslashes again and calls gpgconf. I haven't seen anything in gpgme-w32spawn that would unquote the quotes backslashes. But maybe that's supposed to happen in the background. A comment in the code reads "We have to quote some things because under Windows the program parses the commandline and does some unquoting.", but maybe that's no longer true.

In T6833#181135, @werner wrote:

The fix should go into gpgme to spawn dirmngr with a proper home directory (i.e with forward slashes).

I propose to replace all backslashes in dirinfo with forward slashes so that GpgME always uses/returns paths with forward slashes. Or is there any reason for keeping the backslashes?

We did this on purpose once - For Windows ppl it is just weird to see forward slashes.

I applied a fix to gnupg which also solves the issue.

works in Gpg4win-4.3.0-beta571