First off, I forgot to mention in my first e-mail that this is a very conservative API. Most of the functions are already written and tested, and of the rest only a few will take a decent amount of coding. The others just need to call a verb or some pre-existing Inkscape function.
I tried not to put anything in this draft that I wasn't sure could be implemented.
Signals/Events:
That being said I have been thinking about signals for a while and did not put them in the first draft for two reasons. One, they complicate things a little. Having signals or asynchronous functions requires more knowledge of dbus on the client side and adds complexity. I wanted to keep the first draft simple.
Two, I'm not sure how much work it would be to add them. Sure I could add a hack in sp_document_done, but it is not enough to know there was a keyboard event, you also want to know what key was pressed (for example.) To get the data of an Inkscape event I would need to create EventListeners and register them with EventTargets and parse values and decide which to send and so on for each signal I wanted to expose.
Maybe someone who knows the event system will tell me that there is a way to expose all the Inkscape events at once without having to do a lot of coding for each separate signal I want to send, but I doubt it.
I'll keep looking into it though, it's definitely a possibility and I'm sure it will get done at some point if there is demand for it. Perhaps I'll create a "Proposed" interface to act as a sort of API wishlist.