I think that configurations are the one place where we should be going above and beyond to provide seamless abstractions, because it is a domain where Guix has the capacity to do things that are left to manual intervention on traditional distros. Like one could switch desktops and login managers by translating configurations between them, or by having generic versions of those configurations to be used by both Furthermore, If they were typed and we had parsers for on disk configuration file formats we could import, compare, and merge them. I remember Ludo mention an issue with invalid keyboard layout configuration. I've always wanted to try writing a parser for xkb configurations, then we could generate them and write procedures to arbitrary modify modifier keys, etc.
Services in Guix still feel like they are large traditional procedural scripts. Imagine if you could define service requirements declaratively like "needs a running SSH daemon with a socks proxy" and then the port number would be magically ungexp'd for that service to use and link in without needing to tell the user to go manually set it up. If there were two services both requiring the same thing with different configurations Guix could use logic to determine values that satisfy both. Maybe it sounds extreme, but my personal dream with Guix has always been to create the ultimate end user distro for non technical users, and to that end, being able to eliminate the need to "follow these technical steps one by one modifying the system state" and instead have "Which one do want?, tick the box" and ill generate it for you, with roll backs, and if you change your choice and reconfigure, there want be and random packages and config files littering the file system". If the plasma desktop service could say it requires a login manager configuration, and softly suggests sddm as a default, the the user wouldn't even have to manually add that to their config, it would just be there by default, but could be changed or disabled if the user so desired.
