Agreeing with Don that this is a perfect project for Gtk2Hs, I must also caution against storing anything in GConf. From a usability standpoint GConf is an abomination, ...
I wasn't advocating for GConf per se, only for the idea that whatever configuration format such a GUI-configurator might use stay separate and modular from XMonad base.
It wouldn't be wise to have the GUI molest Config.hs either though,
Speaking very abstractly (which may of course be completely vacuous,) I think the strong Haskeller should be able to write (in Config.hs) code which queries configuration information from a GUI configuration tool plugin, rather than have a configuration tool which manipulates the XMonad state directly by writing a Config.hs or the like. That keeps things modular, allows various GUI builders to design however they like, and doesn't take any power away from a power user. I notice that when I restart XMonad with alt+q, it somehow keeps its state. Having not investigated the code very deeply and only seeing what happens to the description in my process list, it looks like the current state is (pardon my vocabulary) serialized into a string which is passed to the new process and interpreted. Is this right? Please correct me if I have this wrong (because I would love to know exactly how it works.) If it's about right, would it also be possible to do the same thing with the "state" of the GUI configurator? To be specific, serializing its state to a text file when changes are made, and loading it when initialized? Does there exist an elegant pattern among Haskell programs for state serialization over multiple invocations?