My 2c on this, I believe that to be able to pull that off, using a native framework (Gtk, Windows API, ...) is required in order to handle the native behaviour of the platform. It's not that complicated to be able to make an UI framework that can draw basic widgets, but once you want unicode, text input, clipboard, drag and drop, scroll (including touch) this is going to be a nightmare to implement it all in a way that integrates with the platform.
However, the native libraries should only be used for those basic features. All the widgets can still be implemented in pure Nim and should. I second the idea that the widget library should be small and mostly examples, but that the API to create widgets should be easy to deal with. Everyone is going to want implement their own widgets. In order to reconcile immediate mode and retained mode, I imagined that it would be possible to design an API for widget creation that would allow both a retained-style API (draw proc, and event handlers) and an immediate style (simple immediate proc that would draw the widget with the events available). It could be a matter of choice for the widget author to choose one or the other. The window woud be drawn with the same API (the window being a single custom widget composed of many child widgets). Of course creating a widget that contains multiple child widgets should be easy.
