pkcon and pk-glib and aptcc properly support debconfing. discover does not causing debconf to run in auto mode which may have adverse impacts in complicated config update scenarios where people made very specific changes in /etc/.

equally, debconf may be used for license agreement queries (it definitely used to with sun java packages until those disappeared)

debconf being a generic UX system any number of things could be done through it and any number of things may be going wrong if debconf is run in auto mode.

pk-glib to support this has a helper "class" which starts the debconf frontend (depending on desktop and whatnot)
https://github.com/hughsie/PackageKit/blob/194349758a0ad03cb481ccd35322418cbe1f0208/lib/packagekit-glib2/pk-client-helper.c#L403

this is used by pkcon to start a helper and then set the "frontend-socket=%s" hint on the transaction
https://github.com/hughsie/PackageKit/blob/bc9a5d6209a9213a42031d39eecdb35b3955716a/lib/packagekit-glib2/pk-client.c#L1992

aptcc then passes the frontend socket to apt/dpkg so that they can render the debconf UI through the frontend if necessary.

as similar system should be used for discover. possibly with a way for distros to opt out of it? also, this results in the frontend throwing up random windows as necessary, a more integration approach might be taken by implementing a frontend in discover itself (might need some refactoring to get away from qwidgets https://cgit.kde.org/libdebconf-kde.git/)