bug#29072: The usability of Guix configurations

[myglc2]

My system recently broke when I did an upgrade. I reported what I
thought was a bug (bug#29072) but it turned out that, because qemu
package code had been moved, my system configuration had become broken
;-(

Confronted with my situation, helpful developers said "The package code
was moved in commit xxx" (Leo) and "maybe you have a mistake in your
config (Efraim)."

Once I understood what had happened I wondered, "Gee, I have been using
guix for 18 months so why didn't I figure this out myself." ;-)

But a less committed user might say, "Wow, Guix breaks at random, error
messages are hard to understand, and support is difficult."  :-(

ISTM this raises issues and questions about Guix configuration
usability:

Guix config errors are reported as raw scheme errors which are not
user-friendly, except, perhaps, to guile users ;-) Could we improve this
situation by adding config troubleshooting guidance to the doc?

Guix config errors consume meaningful amounts of user and support
effort. I say this because a) it took quite a few iterations to figure
out what was wrong in my situation, and b) google search for '"no code
for module" guix' finds 613 hits, which will no doubt grow linearly with
number of Guix users unless something is done. So I wonder, could an
error handler that translates into more user-friendly terms reduce user
frustration, increase the rate of user self help, reduce support load,
and effectively pay for itself?

Are the current Guix config errors usable by the average GNU/Linux
distribution user? If not, don't they need to be improved before we call
it 1.0?
        
Does this mean that package code must not be moved after 1.0?

Finally: Should I close bug#29072? ;-)