I don't think it's a kernel problem, possibly a dnf cache
issue,
I too think it is not likely to be a kernel problem. A dnf cache problem
also seems unlikely - each try retrieved new copies of the package files
from a mirror, then failed in the same way. After the reboot, I think
the dnf cache would be unchanged - but now the update worked.
I suggest some older versions of tools used by dnf (broken or
incompatible) were in the memory image when dnf upgrade failed. The
reboot loaded up-to-date versions of these tools, and dnf then worked
properly.
However distasteful I find the remedy "Reboot the machine." I have no
sure solution to manage incompatible versions of programs shared by
multiple active applications.
Maybe dnf could become smarter about detection of incompatibilities when
it upgrades a package, and warn the user when a reboot is necessary to
reconcile the active environment with the new disk image, but I believe
there is no strategy that can do this perfectly.
Even if dnf should detect a possible conflict, there is no way it can
know whether a user will attempt some activity sensitive to this
conflict.
At least the problem I observed appears to be safely in the past.