Here we go:

Thanks.

Where do you find a statement that --keyring is deprecated? I planned to to remove it with 2.1 but there were too many requests to keep it and live with the problems of multiple keyrings. Thus the option stayed, it is just so that in addition to pubring.gpg and pubring.gpg we now also have the option for keyboxd - which is the default for new installations.

FWIW, for gpd and vsd we should use a different icon (blue head for gpd and red head for vsd)

Alright, my above putenv option won't work because it modifies the session environment and thus needs to be run for each gpg-agent session (connection). Adding a putenv_startrup option would help here but this way each connection could chnage the environment - also not good. In the end a way to modify the used environment variables, as you suggested, is a better way.

The actual cause here was that right before storing the imported key we need to decide whether to insert or update a keyblock. For this we need to lookup the key in our database and the lookup function does the usual thing by looking at any fingerprint. This is wrong: Here we need to lookup only by primary fingerprint. This is what the above patches do.

That is not a new issue. We have the very same issue since ever. However, without keyboxd you had random results depending on the order of the keys in the keyring.

That is an installation/migration question and the warning is just a convenience thing to remind the few early users of keyboxd to migrate to common.conf.

As usual use ./deadbeef.... as the filename to distinguish it from a fingerprint.

What about deleting the environment variable in gpg-agent:

gpg-connect-agent 'OPTION putenv=DBUS_SESSION_BUS_ADDRESS' /bye

or to use a pinentry-wrapper?

Won't be fixed for the creation thing.

This is the old code from gnupg-2.0/agent/gpg-agent.c:

inotify is already used used on Linux to check for a lost homedir. The once-in-a-minute check should be the same as with the other daemons and has proved to be very useful. The whole thing has been discussed over and over again a long time ago and - as with other system daemon - we agreed on scheduling at the full second.