Today's situation of OpenPGP is a dim situation. There is lack of exposure and the keyservers infrastructure is going all insecure, with the new standard way of only needing a email link to remove a key from the keyserver. Instead of making use of revocation certificates.
This is due to the rise of Hockeypuck keyservers and the fall of SKS keyservers, due to GDPR EU law reasons.
I, myself, dislike this route that is being traced, and want to make SKS keyservers the most prominent keyserver again, because it relies on revocation certificates, instead of email links, for key "invalidation". But the EU's GDPR claims are valid and must be fulfilled in today's age.
I am thinking about this scenery, and I think I have got the solution, that may make OpenPGP keyservers infrastructure secure again... and this solution requires a feature in GnuPG (and any OpenPGP client). This solution is similar to "why doesn't Microsoft Github gets sued by GDPR complains of git's personal info hosting".
It is all about the git's mailmap file feature, and I basically want GnuPG to also have a mailmap file feature. So that keyservers may easily "remove" (or disconnect) personal info (email, name and photo) from the keys of their GnuPG keyring's server.
So basically GnuPG could have a mailmap file and any entry of this file makes GnuPG "substitute" the corresponding key personal info (email, name and photo) with the info in the mailmap file's corresponding entry. This substitution can be made of GnuPG key listing output. This idea is similar to git's mailmap -> https://git-scm.com/docs/gitmailmap/
It could go even further and make a option, related to this mailmap feature, where any key personal info (name and email and photo) imported, would be substituted by default the a stub (such as user0000001, user00001.sks.noreply@mysksserver.com, and a anonymous default photo), and, in the mailmap file, a entry of the real personal info would be added automatically. So, this way, if a user wants to delete it's data from the keyserver, the keyserver admin would only delete this user entry on the mailmap file, leaving no trace of this user personal data on the keyserver's files.
I hope that I am making this idea clear enough, but if you need any further understanding, I will happily try to clear any doubts in this thread. This feature idea is basically taken away from Git's mailmap feature (the link is above, where you can read more).