The problems with using concurrent.futures directly for running synchronous tasks in the background are:

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)
3. There's no easy way for background tasks themselves to use asynchronous IO

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.

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.