I think there's a strong case for a generic __frame__ attribute, since there are plenty of useful things you can do given "object with a linked frame" as a protocol (like extract the current locals namespace). We may even want to include traceback objects in that particular attribute access consolidation (since they have a tb_frame attribute).

Looking at the way inspect.getgeneratorstate() and inspect.getcoroutinestate() are implemented, I also think there may be a case for consolidating `[gi|cr|ag]_running` into a single `__running__` attribute, such that for objects that provide a `__frame__` attribute:

* `__running__` doesn't exist -> not an asynchronous operation
* `__running__ = True` -> running asynchronous operation
* `__running__ = False` -> paused or halted asynchronous operation

Then, rather than adding an inspect API specifically for async generators, we could add a general "inspect.getasyncstate()" one that covered all the object types, with the possible states:

    ASYNC_RUNNING: __running__ == True, assert __frame__ is not None
    ASYNC_CREATED: __running__ == False, __frame__.f_lasti == -1
    ASYNC_CLOSED: __running__ == False, __frame__ is None
    ASYNC_SUSPENDED: __running__ == False, neither closed nor created

Properly interpreting `gi_yieldfrom` and `[cr|ag]_await` is a bit trickier, since they require additional knowledge of how the control flow for those objects actually work. However, if we run with the "async operation introspection protocol" idea, then a suitably generic name would be `__async_call__`, and we could make it a doubly-linked list for the coroutine and async generator case by setting an `__async_return__` attribute on the target (to say where we expect control to return to when we're done).