@dominic Sorry, to be specific I mean "can multiple unboxers try to unbox the same content?" and if so "how should that be handled?". This seems analagous to depject.

I think we have a few options:

• first: This is what we're currently doing, which means that if main_unboxer returns plaintext that no other unboxers are tried. This also has the downside of being sychronous.
• race (async first): The async version of first, where all of the unboxers are started and the first one to finish gets to unbox the content. This is the minimum change necessary to allow async unboxers, and basically moves the priority from "first in the array" to "first to return successfully". To be clear, I mean a literal Promise.race(), not an unplanned race condition.
• merge (reduce): This is the behavior of the current PR, which calls all of the unboxers, waits for them, and merges the successful ones into an object that's returned. My concern is this is slow, complicated, and seems to provide no benefit as the current unboxers would never operate on the same data.
• walk (recursive reduce): A computational nightmare, this would be trying every unboxer, merging the results, and retrying all of the unboxers with the new result. This process would continue when the unboxers stop returning modified data. Again, it's a nightmare, but it's the only way to do stuff like _unbox(blobs.get(x)) with an arbitrary number and order of unboxers.

My PR would move from us from "first" to "reduce", but the more I think about the problem the more I wonder whether "race" is a better call. We don't get any additional benefits from merging results unless we go full-pickle and recursively walk through every unboxer combination, which gives me the impression that "race" solves our problem of synchronousness without inheriting a new monster.