I think that’s definitely an advanced approach. Most people would just add the other DE and then pick it from the gdm login screen, like the instructions in https://docs.fedoraproject.org/en-US/quick-docs/switching-desktop-environments/#installing-desktop-environments
If you are doing dnf swap, throw in changing the fedora-release-identity-... and there you go, right?
Not really. If you google it almost all the instructions out there will tell you to use dnf swap and people just type it blindly.
The Fedora doc came up first for me in my blind search, but I looked and found some others. One says
dnf swap @gnome-desktop @kde-desktop
… and if you do that, you might run into this problem. But if you do:
dnf swap @workstation-product-environment @kde-desktop-environment
that should also change the identity.
I think you will have the same problem no matter what. Because even if the file in protected.d would be removed by the swap, the evaluation would happen before that occurred. Am I thinking about that right?
Also, in my experience, it is much harder to make that swap work than the prior one. There are almost always strange conflicts. The only way I have been able to make that work is to do it in a transaction and fix some things manually which is most definitely something only an advanced user could do.
However, this:
Usually, “just works” in my experience.
I’ll have to take a look at the details. I agree that it ought to be relatively easy, but I also think it’s better for everyone if changing the desktop changes the identity, so we should figure out how to make that as seamless as possible.
If that is installed in Fedora Workstation and a dependency of a protected package, then dhcp-client and iproute loses its use case for recovery through chroot (I need to test), it could be safely removed in this case.
I agree with @dalto . I have had a lot of issues with gnome-software and shun it like poison ivy. Although it is used for package updates/installation by a lot of users, making it protected seems extreme. Especially for those users who want only a minimal system. Mandatory things for operation should be protected, and only those mandatory things.
IMO For minimal systems folks should use the everything iso and trim from there Vice workstation.
The documentation should be updated to include how to do disable/enable/remove the third party repos since that seems to be desired and it’s not a straightforward process for a new or average user.
I don’t disagree with that approach but I think there is a difference between a “minimal” system and simply wanting to remove gnome software without jumping through hoops.
Basically I don’t see the need for gnome as a protected package either. But I also don’t see it as a big problem. The extra work for advanced users is (in my opinion) hardly worth mentioning.
But since there is already talk about different installations: with such influential policies (with regards to GUI & protected packages), the potential inconsistency between workstation, server and the spins bothers me the most.
If Fedoras behave differently in install/remove/cleanup-activities, this is where I see the most potential for problems (or user mistakes): how many users will always remember during relevant activities that what is potentially removed is not the same in each Fedora? Finally, gnome has comparably much dependencies and thus, much more impact than e.g. NetworkManager when handled differently among Fedoras.
People are creatures of habit (even advanced users), and therefore standardization is the best problem prevention.
Just a few thoughts that could be considered in the discussion and decision 
Forget what I said entirely, I have taken the time to test the Internet connection in a chroot jail without iproute and dhcp-client, but having NetworkManager installed, I don’t even need to type dhclient, now I only need NetworkManager, gnome-software/gnome-terminal, mesa-dri-drivers and kernel-modules to have a working Fedora Workstation. Thank you for teaching me about NetworkManager.