I'm in agreement here.  While I can appreciate why another user might want to wrap up all their configuration options in a single object, I don't think the classes in the gem should be dependent upon that.  

My initial suggestion was a bit less ambitious than Dave's -- simply supporting a :configuration key in the options and passing in the Configuration class on that option.  This makes the API a bit more "rubyish" than "javascriptian"(TM). However, I think that what Dave is suggesting is more appropriate since the gem consumer could hold onto options in whatever way they choose.  As Dave has suggested, that could include using the provided Config object.