Here's one approach to keeping config information at the library level. IMHO, a key philosophical point is that this metadata is associated with a database, not with the library.
Having every key map to a distinct file is arguably not as nice for humans to edit, but it avoids certain concurrency complications; e.g. glib can atomically write a keyfile (like we use for .notmuch-config), but that means e.g. the result of two concurrent updates to different keys is not a valid serialization. It won't be very efficient for huge numbers of keys, but for keeping some static metadata associated with a notmuch database, this should work ok. In addition to needing some polishing (documentation? what documentation?), this isn't actually used anywhere in notmuch.
