I, too, think I ran into basically the same situation as Paul: An outer async generator calls an inner async generator. The outer doesn't fully consume the inner. The inner uses an async context manager. The inner CM isn't exited when expected and resources aren't released when required/expected.
FWIW, the analysis of PEP 533 seems spot on -- for synchronous code, while still possible, it's harder to trigger thanks to the GC tricks. For asynchronous code, it easily (and subtly) results in resources not being released when expected. Or perhaps never at all? IIUC, a long-lived server might just accumulate unfinished async generators indefinitely, or at least until some OS resource was exhausted.
In my particular case, I have thousands of network requests to make, each of which is potentially large and/or slow to complete in its entirety, so I'm taking extra care to break early to minimize resource usage to both client and servers. I spent about an entire day trying to figure why the synchronous version of my code Just Worked, while the asynchronous version simply refused to close things when I was done with them. It was only after I started looking at third party libraries and stumbled upon
a reference to PEP 533 and a detailed blog post from 5 years ago that I had a clue what was going on. My point being, the feature PEP 533 describes would have made things Just Work in line with my expectations.