@David House:
That is under discussion. One reason not to is that xmonad-light itself depends on parts of xmonad-contrib. Currently just EZConfig, but that will change as xmonad-light adds support for more contrib modules (ManageDocks, more Layouts…).

One of the comments on the reddit thread points out a subtle problem I hadn’t spotted.

The standard xmonad binary, finding no xmonad.hs, runs the default config. Finding a broken config, it pops up an xmessage with the errors and keeps running as it was. This is the Right Thing: falling back to the default config (with possibly wildly different layouts and key bindings, no ManageDocks, etc.) is far more disruptive than failing to load the new configuration but continuing to run.

Care is required, then, when restarting xmonad-light, to distinguish between an extant but broken xmonad.hs (keep running as it was), and an xmonad.hs that can’t be used because GHC is not installed, or the xmonad and xmonad-contrib libraries are not installed. In the latter case, what should it do?

Working on a principle of least disruption to the user, it seems better to stop if an xmonad.hs exists (even if GHC or xmonad isn’t installed), and inform the user so. Fail to restart and let the original instance keep running normally. Cascading to xmonad.conf (or even to the default) could be potentially very disorienting.

Fortunately that makes the problem of distinguishing why loading the xmonad.hs failed moot: If the file exists, xmonad-light either succeeds in loading, or continues running normally.