While https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5#Applications_that_uses_DNF_or_LIBDNF_API describes how Fedora plans to migrate from dnf to dnf5, it doesn't go in with a comprehensive scope:

while improved performance is nice when a package manager is run waiting for its completion (for example, when using dnf in a Dockerfile), the way most Desktop users encounter package management is through their graphical package manager, that being KDE's Discover, or GNOME Software. Both depend on PackageKit, not on libdnf(5) directly. Also, the point where dnf's lack of speed becomes most annoying on the command line is when command-not-found is called, which, you guess it, uses PackageKit.

So, for end-users to benefit from dnf5, we'll need to focus on PackageKit supporting libdnf5. I've had a a look at the code of the dnf backend. It's impossible to port that to libdnf5, because it's C, not C++, and as far as I can tell, there's no sane way of exposing a C API that would be somewhat similar to libdnf's API.

Thus, that necessitates a from-scratch design of a C++-written dnf5 backend (fulfilling the backend C API) I guess. Is that something that is planned?

I raise this issue because as long as PackageKit doesn't do dnf5, dnf5 will never replace dnf and that will lead to sustained double maintenance effort.