Hi Andy,

Thank you for the help!  Sorry for the late reply; I wasn't able to
respond until just now.

> Here the #:system system was taking the `system' binding from within the
> function -- it was lexically bound.

You're right; that was the problem.  I've updated the patch (see
attached) and applied it again to
7972d8a2e98af6592050a37036c2c80a01358fcf, but when I built the new
version and ran './pre-inst-env guix system list-generations', the
following new error occurred (after successfully printing the list of
generations):

--8<---------------cut here---------------start------------->8---
Generation 1	Jul 29 2016 08:26:37
  file name: /var/guix/profiles/system-1-link
  canonical file name: /gnu/store/90xaq1d04g39c1wmxplngh3hhc1h5z7g-system
  label: GNU with Linux-Libre 4.7 (beta)
  root device: /dev/sda1
  kernel: /gnu/store/p7wbfpbs8p8ykdrn1440f95ap9iq1czh-linux-libre-4.7
Generation 2	Aug 03 2016 07:35:00
  file name: /var/guix/profiles/system-2-link
  canonical file name: /gnu/store/6il3znhh2cyp3xw0800x6m3yjq8jq5z9-system
  label: GNU with Linux-Libre 4.7 (beta)
  root device: my-root
  kernel: /gnu/store/p7wbfpbs8p8ykdrn1440f95ap9iq1czh-linux-libre-4.7
Generation 3	Aug 03 2016 07:38:12
  file name: /var/guix/profiles/system-3-link
  canonical file name: /gnu/store/74d698pk4dwv4k4bvf2n4b7j4bg0gbq0-system
  label: GNU with Linux-Libre 4.7 (beta)
  root device: #vu8(18 55 238 217 114 62 64 185 130 140 206 84 109 78 188 217)
  kernel: /gnu/store/p7wbfpbs8p8ykdrn1440f95ap9iq1czh-linux-libre-4.7
Generation 4	Aug 03 2016 07:55:20	(current)
  file name: /var/guix/profiles/system-4-link
  canonical file name: /gnu/store/01fd40gf19syn493y2f6h35cb58kqmg4-system
  label: GNU with Linux-Libre 4.7 (beta)
  root device: #vu8(18 55 238 217 114 62 64 185 130 140 206 84 109 78 188 217)
  kernel: /gnu/store/p7wbfpbs8p8ykdrn1440f95ap9iq1czh-linux-libre-4.7
Backtrace:
In ice-9/boot-9.scm:
 157: 15 [catch #t #<catch-closure 26304a0> ...]
In unknown file:
   ?: 14 [apply-smob/1 #<catch-closure 26304a0>]
In ice-9/boot-9.scm:
  63: 13 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 12 [eval # #]
In ice-9/boot-9.scm:
2401: 11 [save-module-excursion #<procedure 264f940 at ice-9/boot-9.scm:4045:3 ()>]
4050: 10 [#<procedure 264f940 at ice-9/boot-9.scm:4045:3 ()>]
1724: 9 [%start-stack load-stack ...]
1729: 8 [#<procedure 2668ea0 ()>]
In unknown file:
   ?: 7 [primitive-load "/root/guix/scripts/guix"]
In guix/ui.scm:
1209: 6 [run-guix-command system "list-generations"]
In ice-9/boot-9.scm:
 157: 5 [catch srfi-34 #<procedure 52af180 at guix/ui.scm:425:2 ()> ...]
 157: 4 [catch system-error ...]
In guix/scripts/system.scm:
 884: 3 [#<procedure 52ae750 at guix/scripts/system.scm:876:2 ()>]
 818: 2 [process-command list-generations () ...]
In guix/store.scm:
1182: 1 [run-with-store # ...]
In unknown file:
   ?: 0 [#<unspecified> #<build-daemon 256.15 52b8e80>]

ERROR: In procedure #<unspecified>:
ERROR: Wrong type to apply: #<unspecified>
--8<---------------cut here---------------end--------------->8---

I'm hoping you can help me (1) understand this particular problem, and
(2) help me learn to become more self-sufficient at troubleshooting
these kinds of issues going forward.  I don't want to have to bother you
or the mailing list every time I encounter a stack trace.

Regarding (1), I'm having trouble understanding this particular stack
trace.  Where did the error occur?  What caused it?  I'm used to stack
traces in Java and Python, where often the exact line which threw an
exception is usually obvious in the stack trace.  I'm finding Guile's
stack traces more difficult to understand.  Maybe I'm just not used to
them yet.

Regarding (2), I've read some of the manual at '(guile) Debugging'
(mainly '(guile) Evaluation Model' and '(guile) Programmatic Error
Handling'), and although it's great and detailed, it isn't obvious to me
how to apply that knowledge in practice.  For example, I'm not even sure
how to find out what the parts and symbols in the above stack trace
mean.  How can I get better at this?  Should I just read the rest of
'(guile) Debugging' in detail, and experiment with my own toy programs
until it makes more sense?  Or is there a common tool people use for
debugging that I'm not aware of, like how pdb is a common debugging tool
for Python programs?

Again, thank you for your help.  I really appreciate it!

-- 
Chris