> - I would say event loop per class.  If someone really needs event loop per method, they can create separate classes per method.  It's ugly, but effective.

+1.

- We should have an async setUp capability.  Maybe we could add a helper method to be called from setUp rather than adding a whole new asyncSetUp into the protocol?  That eliminates the problem of which goes first.

I'd rather have a protocol :)  Protocols are easy to document and it's possible to statically validate them (with linters/metaclasses).  Calling some method from setUp to call asyncSetUp would be a common gotcha IMO.

We can always call synchronous setUp before asyncSetUp, I think it's intuitive enough.

Speaking of addCallback, we should have a distinct addAsyncCallback.  It's OK to have an object with both __call__ and __await__ methods -- in which case it's not clear which one you should call.

In general, while we will be adding a new subclass and a few 'async'-prefixed methods, it should still be relatively straightforward for people to write and, more importantly, read the code that uses them.