Fedora, like various Linux distributions, has a system of 'alternatives', where several programs from several different packages can provide alternative versions of the same thing, and which one is used is chosen through symbolic links in /etc/alternatives (Fedora's version appears to be this implementation). These alternatives can have priorities and by default the highest priority version of something gets to be that thing; however, if you manually choose another option, that option is supposed to stick. On a Fedora system, you can see the surprisingly large list of things handled this way with 'alternatives --list' and see about a particular thing with 'alternatives --display <thing>'.

As part of its attempt to move to Wayland, Fedora 40 has opted to package two different builds of Emacs, a "pure GTK" build that does not work well on X11 (or on plain terminals), and a "gtk+x11' build that does work well on X11 and on plain terminals. Which of the two versions gets to be 'emacs' is handled through the alternatives system, and the default is the "pure GTK" version (because of Fedora's love of Wayland). I don't use Wayland, so more or less as soon as I upgraded to Fedora 40, I ran 'alternatives --config emacs' and switched my 'emacs' to the gtk+x11 version, which also sets this alternative to be manually configured and thus it's supposed to be left alone.

Fedora 40 shipped with Emacs 29.3. Recently, Emacs 29.4 was released to deal with a security issue, so of course I updated to it when Fedora had an updated package available. To my unhappy surprise, after the update my 'emacs' was suddenly back to being the pure GTK, Wayland only version. Unfortunately, this outcome is actually a natural one given how everything works, because I left out a critical element of how Emacs works with the alternative system in Fedora. You see, when I manually set my alternatives preferences, I did not set it to 'emacs-gtk+11', because there is no such alternative. Instead, I set it to 'emacs-29.3-gtk+x11', and after the upgrade I had to reset it to 'emacs-29.4-gtk+x11', because that's what now existed.

Quite sensibly, if you have an alternative pointed to something that gets removed, Fedora de-selects that alternative rather than leave you with a definitely non-working configuration. So Fedora removed my (manually set) 'emacs-29.3-gtk+x11' alternative, along with what had been the default 'emacs-29.3' option, and after the package update it had 'emacs-29.4-gtk+x11' (at priority 75) and 'emacs-29.4' (at priority 80, and thus the default). With no manual alternative settings left, it picked the default to be 'emacs', and suddenly I was trying to use the non-working pure GTK version.

This is all perfectly natural and straightforward, and in this situation it more or less has to be implemented this way, but it results in a less than ideal outcome. To solve it, I think you'd need an additional level of alternatives indirection, where 'emacs' pointed to an 'emacs-gtk+x11' or 'emacs-pure' alternative, and then each of these pointed to the appropriate version. Then there would be a chance for the alternatives system to not forget your manual setting over a package upgrade.

(There might be a simpler scheme with some more cleverness in the package update actions, but I think it would still need the extra level of indirection through a 'emacs-gtk+x11' symbolic link.)

All things considered I'm not surprised that Fedora either overlooked this or opted not to go through the extra effort. But still, the current situation is yet another little example of "robot logic".