There are
2 TODO: (async) in intrtroputil.cpp
3 TODO: (async) in dispatchinfo.cpp
1 TODO: (async) in comtoclrcall.cpp
2 TODO: (async) in clrtocomcall.cpp
2 TODO: (async) in commtmemberinfomap.cpp

In my understanding these are all related how async methods are (not)exposed through COM.
We need to follow up on that and remove the TODOs as a result of either:

• confirming that what we have is correct. Perhaps add a comment why it is correct.
• fix the code and ideally add tests.

We need some rational story on what happens with COM interop in the presence of Runtime Async. Even though it would not be common to work with methods that returns Task/ValueTask via COM interface, such cannot be ruled out.

I.E. reflection pretends that synthetic async variants do not exist, and Async methods that are actually in the metadata (like AsyncHelpers.Await), while exist, cannot be invoked.

Not sure if a similar model would fit COM interop. Perhaps with adjustments for when presence of async variants in methodtables will unavoidably leak. If COM may have dependencies on the actual layout of method table, we may have compatibility issues. Some existing code may get broken just because runtime async is enabled.
If unavoidable, we should at least document what happens and how to deal with that.

One example of code that could observe the mere presence of Runtime Async feature:
#114675 (comment)