I confess I don't really understand what the bug is, but I know vaguely from the mailing list (mostly Conal) that there's some sort of GHCi-related bug.
See this Haskell-Cafe thread
Not filing this for the upcoming release so much as something we want to keep aware of.
Here's what Jeremy had to say about it:
When I last looked at the problem, the issue was that wxWidgets libraries use static constructors and destructors in some places.
Problem with static constructors is that they typically run before main() - or its equivalent - is called. This means that once you quit an application, there is no way to restart without relaunching executable.
Similarly, static destructors only run after app has called exit().
There were a couple of approaches I considered:
Implement a wrapper which forces dynamic load and unload of the wxWidgets libraries from inside wxc. This would work because when reloading the libraries (as you would when restarting app at GHCi), the static constructors run (e.g. in Windows they usually run just before DllMain() is called). This is easy, but very tedious to do in practice, and would only really make sense if the wxWidgets bindings are auto-generated.
Fake application exit when running in GHCi so that when app starts again the same event loop is used, and the static destructors are never called. This would be a very neat solution, but state management is very tricky.