Jonathan Hall

> We might want this to be its own module, to not add further deps to the main package. I don't think it adds any deps anyway. The only change...

> btw, @flimzy test failures are caused by a new option added via #490 Thanks for the tip. Addressed in 95a2bee9d55132df3fa99b08dfe2b094a2062eb7

I think the callback should be optional. Unless I'm overlooking something, this code will panic when no callback is defined.

Sorry, I didn't ralize that `LevelHooks` was part of the public API. I'm also a bit confused as to why it is, since it's documented as an 'internal type'. I'll...

I've pushed a new implementation of this PR, which retains the original `LevelHooks.Fire()` API. It adds a new, unexported type, to report all errors. If we think others will call...

Thanks for the additional comments. How would you feel about a configuration option to enable this behavior? I think it would be possible to add a config option to the...

I've updated this PR now with the new configuration flag (off by default). Please let me know your thoughts.

So I'm digging into the error proposals for Go, and the closest relevant one I think is [this](https://gist.github.com/gregwebs/5a14a83970d607411310a3e0281d55be). It's only a proposal, and probably won't be accepted as is, at...

I've updated the PR once again with some changes to multi-error handling. I don't know if any or all of it is a good idea. I welcome your thoughts :)

> I'd like to take a look at supporting go1.13 error wrapping if possible What, specifically, would you like to support here? I added `Unwrap()` to the `multiErr` type, but...