> 1. You have to manage the lifecycle of the executor yourself, rather than letting asyncio do it for you
> 2. There's no easy process wide way to modify the size of the background task thread pool (or switch to using processes instead)

But if that's what you want, adding a helper or helpers to concurrent.futures makes more sense than adding it to asyncio, which is primarily about using an event loop, *not* threads.

> 3. There's no easy way for background tasks themselves to use asynchronous IO

But how does your proposal help for that? The function passed to background_call() is in no way enabled to do async I/O -- it has no event loop and it is not a coroutine, and it's running in a separate thread.

> With the switch to "background_call" as the name, I'd modify the implementation to detect coroutines and schedule them as tasks rather than running them in the executor.

Honestly, I think that convenience routines that fuzz the difference between synchronous functions (to be run in a thread) and coroutines don't do anyone a service -- an API should educate its users about proper use and the right concepts, and this sounds like it is encouraging staying ignorant.

> However, I think it's clear that the idea and its potential benefits are sufficiently unclear that making the case effectively may require a PEP. That's probably worth doing anyway in order to thrash out more precise semantics.

Or you could just give up. Honestly, I am liking this less and less the more you defend it. That's a classic sign that you should give up. :-)