For the most part, very straightforward and welcome improvements (especially the passing of exception context).

There are a couple of themes in my review comments:

• Consistency in the as e addition. It's inconsistent where you've used as e, as error, as exception; unless there's a syntactic ambiguity, I'd argue it's better to stick to as e across the board.
• Line length. I've got flake8 set up to accept 119 character lines; but that shouldn't be taken as an invitation to make lines long just because you can :-). There's a lot of places (some of which I've flagged explicitly) where pulling out the newlines dramatically reduces readability. In particular, complex comprehensions benefit from being split over multiple lines because the operative clauses are need to be independently understood. Breaking a single 119 char line into 3 lines that are "the pattern for each item", "the list being iterated", "the condition on list items" makes it a lot easier to digest what is going on. The 119 line limit is really there because there are rare occasions where lines need to run long; unless you've got a good reason, black's 89 char line limit (80+10%) is a good rule of thumb to aim for.
• Similarly, while 119 characters allows you to reduce short if/else statements to a single line, that's not always desirable; Yes, an if-then statement is 4 lines - but we're not paying Github by line count :-) If there's even slightly complex logic in an if/else statement, I'd argue using multiple lines is preferable, even if the single statement will fit in 119 characters. Broadly speaking, the only context in which I really like X if Y else Z as a syntax construction is in a comprehension; in almost every other situation, I find the condensed syntax harder to read.

One bug (picked up by the test suite), and one minor (and possibly optional, if you're not feeling it) cleanup flagged inline; otherwise this is looking good.

As for black - that's on my list to look at :-) I was primarily waiting until black declared themselves "non-beta"; that happened earlier this year, so it's now down to the mechanics.

I've just run black over the Briefcase codebase, and the changes are 80% '->'"' by volume; there are a handful of other changes that grate against me a little bit, but not as much as the overhead of having to review code format :-) (or, in some cases, can be made palatable by making a small tweak to syntax).

The biggest impediment to "just doing it" is working out what black looks like from a CI and repo config perspective. If we're going to adopt black, it needs to be applied automatically without any explicit interaction from users (because I don't want to adopt a tool and then spend every PR review saying "Could you run black over this code"). Investigating what 'best practice" looks like is the next step on this journey.

Awesome - thanks for the cleanups!