Summing up from the comments:
It's again Gravatar's servers screwing up things – and nothing SE could do about it. For understanding:
- the
d
parameter is not about what type of icon to use – but it tells Gravatar which icon generating algorithm to use when there is no image attached to that email hash. It is not an override - that is the f
parameter. If Gravatar is returning a pattern, then something is messed up with Gravatar (again).
- the issue sounds like Gravatar just glitched and the one set to
identicon
is cached incorrectly - meaning that it will eventually correct itself whenever that image expires. SE cannot use d=gravatar
as a general replacement to the current d=identicon
(which was always used here) – because for users who are not set up with Gravatar this would result in this profile image:

- The "Gravatar" option in the user profile treats your email normally, letting your Gravatar shine through or using the Identicon if none exists. The "Identicon" option is a forced method which also changes the hash which gets sent along completely. It's perfectly possible that an Identicon would still be shown using the "Gravatar" option on our site, because it doesn't guarantee that the user actually has an image there. So anyone with that set will end up with a bunch of generic blue Gs which we do not want. So while the names correspond to the
d
parameter, they are there for a different purpose.
Bottom line: SE has always used the identicon
option there, since creation. It's never changed. All that's happened is something on Gravatar's servers screwed up the image for that particular size, and it will eventually correct itself on its own given time. There's nothing we need to do here but wait.
Gravatar has been experiencing a lot of issues lately, so it's not clear how long it might take until it resolves itself. There were so many issues that SE has looked into dropping it completely and finding an alternative profile picture option. It's annoying to have to support users trying to use a service where some 3rd-party service keeps doing random things that are completely unexpected, and all SE can say is "it's not us, it's them." But unfortunately, their support seems to be virtually nonexistent and until SE comes up with an alternative, we just kind of have to deal with their nonsense.

PS: As explicitly asked: "Why does it only affect the avatar shown in questions and answers but not the avatars in profiles?" It could also be the other way around. Just depends what size Gravatar messed up. See the text of my question: In my case, something went wrong with s=32
, the small avatar which is used in the signature added to questions/answers. Their CDN cached the broken version of that, but the correct version of the bigger one (s=328
).
PS2: As pointed out by Shadow Wizard, the issue can be "worked around" by uploading the avatar image directly (instead of relying on Gravatar). SE then uses Imgur to store it. Do so, don't change any other profile detail, and hit the button to update on all sites – and this will update the avatar only, leaving all other details untouched (important if you've tailored those specific to the site, as I have).
d
parameter tells Gravatar which icon generating algorithm to use when there is no image attached to that email hash. It is not an override - that is thef
parameter. If Gravatar is returning a pattern, then something is messed up with Gravatar (again).d
parameter togravatar
. Maybe that should be done by SE if the user has set it such? Even ommitting thed
parameter resolves to the correct image.identicon
is cached incorrectly - meaning that it will eventually correct itself whenever that image expires. We cannot just change it togravatar
because then it will display this for all users who are not set up with Gravatar.d
parameter should honor that.identicon
option there, since creation. It's never changed. All that's happened is something on Gravatar's servers screwed up the image for that particular size, and it will eventually correct itself on its own given time. There's nothing we need to do here but wait.s
parameter to retrieve a different size image depending on how large they're displayed in that location. That way users aren't downloading a giant 256x256 profile picture on pages that only display it at 32x32. It makes more sense to just download a 32x32 image in those places.