Personally, I wouldn't worry too much about pluggable systems to store configuration data. The "public" interface for configuration information can be a configuration file. It works for almost every other system service I work with. I can then use something external (puppet, chef, a bunch of home grown shell scripts talking to MySQL, whatever) to generate that configuration file. Doing it this way neatly decoupling the actual config from the way it's stored and distributed, and means you don't have to care about supporting a whole bunch of extra dependencies.
That said, I think there's a certain elegance to storing the connection information as SRV records in DNS. :) Then you just need to configure applications to look for a well known service name to get the connection details. On the other hand, that's not really flexible enough to distribute anything more than host/port information, so you still need admin configuration files…
On the third hand, nanomsg is fundamentally a library, and it's not the "role" of the library to configure itself. That's the responsibility of the host application it's integrated with. I personally dislike the notion that log4j has its own separate configuration file in every Java app I deploy, for example (while the log4j config format is consistent across apps, the actual configuration data is very app specific, so there's no real benefit to it being in a separate configuration file!). Perhaps the goal of nanomsg is to make the API amenable to easy configuration (though I'm not sure exactly what that means!)?
Anyway, this is random drive-by commenting from an outsider, who doesn't understand the broader conversation, so feel free to take it with a pinch of salt. ;-)