1) gtk_image_new_from_file (gtk_image_new_from_file_utf8 in my case) calls gtk_image_set_from_file
2) gtk_image_set_from_file calls gdk_pixbuf_animation_new_from_file on the filename. Note that this code is decade-old.
3) gdk_pixbuf_animation_new_from_file () finds a module to use (png module ranks at 100 and is used - as expected).
4) png module does not provide load_animation (as expected), but provides begin_load, so gdk-pixbuf uses that.
5) gdk-pixbuf calls:
context = image_module->begin_load (NULL, prepared_notify, NULL, &animation, error);
However, prepared_notify is never called by the png module (it probably will be called later, once the loading process beings).
Because prepared_notify is never called, the "animation" variable it is supposed to fill remains NULL.
6) if (!context || !animation) { goto fail_progressive_load; } (note that context is non-NULL, only animation is NULL)
7) Thus gdk_pixbuf_animation_new_from_file() fails
8) gtk_image_set_from_file() uses the "missing" image instead.

Possible cause:
gdk-pixbuf came to depend on prepared_notify() being called by a loader module after just preparing the reading process (presumably - reading the header).
This is not really a requirement. prepared_notify() code will just call gdk_pixbuf_non_anim_new() for non-animated images (or ref existing GdkPixbufAnimation object for animated images), and store its pointer in user_data (the &animation).
After that the &animation is not used until it's time to return the loaded image. The code doesn't really need to check that animation is non-NULL that early.

Instead it should only check that context is non-NULL, and then proceed to load the image. Only check for animation being non-NULL once the loading process is complete (or failed).