Actually, this might be a major issue with using threads.
The way Future objects work, set_result()/set_exception() directly calls all the registered callbacks, which include async_step above, and that calls the next step within the coroutine.
So, when the worker thread finishes working with the subprocess, it calls future.set_result() and that ends up causing the next part of the coroutine calling async_subprocess to run within that thread as well, completely unsynchronized with any other async code in roled and quite possibly accessing the same data (e.g. the instance objects).
Using the GLib design of thread-safety-by-no-locking-and-executing-everything-on-the-same-thread, we would need to ensure that the next part of the coroutine runs on the main thread, i.e. creating a GSource that poll()s for something set by the thread worker; using (logically) a condition variable, or (usual implementation?) a helper pipe and unix_fd_source_new.
This is starting to get complicated…