And actually of course, the standard Error.message doesn't support passing back structured data like the arrays we use for formatted errors in this file.  So it seems like we have three options:

* Use the success argument with an 'error(s)' property for most problems -- anything other than unexpected, thrown exceptions.  _(Seems a little gross and not really how most Node treats anticipated error cases)._
* Use a custom Error subclass that accepts a (non-string) data parameter, and add special logic to ConnectionManager to serialize back that parameter.  _(Doesn't seem that common in Node either, but still a bit cleaner than above)._
* Pass something other than an Error as the first arg ([some references](http://stackoverflow.com/questions/8513703/node-js-convention-for-returning-multiple-errors-via-callback) say this is ok).  _(But definitely not the standard Node way)._

Right now our code seems evenly split between the 1st & 3rd approaches, which is not that ideal...