Files for which thumbnail generation has failed more than 4 times in 1 hour are throttled for 1 hour. As I understand it, uploading a new version does not reset this counter for the new version because of how the URLs for original files are created and how the throttling is implemented. I've tested the new version locally without error, and a thumbnail should be generated when the throttle timer runs out.

As far as the error message goes, it would be difficult to provide further information there. The 429 happens at the caching layer (in this case), which has no information about why the file is being throttled. T175512: thumbor 429 throttled error messages are confusing is the task for that though.

Personally speaking I'm a bit puzzled why we (Wikimedia) allow uploads in XCF format. That feels wrong. Quoting https://en.wikipedia.org/wiki/XCF_(file_format):

the use of XCF as a data interchange format is not recommended by the developers of GIMP, since the format reflects GIMP's internal data structures and there may be minor format changes in future versions.

I could imagine the latter might be the case (but have no idea how to find out).
https://gitlab.gnome.org/GNOME/gimp/-/commits/gimp-2-10/devel-docs/xcf.txt for the history of the spec.

The thumbnail for the new version is now visible.

This task could be retitled and left open to discuss how memcached throttling deals with overwritten files, but I don't think there's any real likelihood that it will change without T149847: RFC: Use content hash based image / thumb URLs.

As for why XCF? The answer is that we've supported it since 2006 T3410: Allow .XCF uploads on Wikimedia web sites and continuing support for it has been easier than deprecation. The xcf2png we use, https://github.com/j-jorge/xcftools/, is not actively maintained and has multiple open CVEs (https://github.com/j-jorge/xcftools/issues), so we'll probably have to look towards that route sometime in the not-too-distant future.

@Aklapper I created T260286 to explore deprecating XCF.