My use case is for a non-async context manager, and if we take track_entry_and_exit as an example that's non-async as well.

The explicit approach (e.g. separate base class for decorators applied to sync vs. async functions) doesn't seem ideal, because it precludes having a single context manager for both cases.  track_entry_and_exit is an example where a context manager would want to decorate both types of functions.

I'm not sure how big of a problem the iscoroutinefunction() limitation is-- in Trio style we don't pass around coroutines by normal functions.  The `async` qualifier exists to make it clear when a function returns a coroutine, and ContextDecorator already doesn't work for the case of a regular function returning a coroutine.  I think the scope here is to enhance ContextDecorator to work with async functions which are properly qualified with `async`.