The problem here is that we need an I/O object which needs to be bound to an I/O service object (not sure how familiar you are with Boost.Asio?). Now what's the I/O object in Boost.Process? Shall we think of a process as an I/O object? Can we expect developers to prefer using asynchronous I/O just as they do with sockets for example? If we don't want to force developers to create an I/O service object whenever they work with Boost.Process we need to find another mechanism to turn a process object into an I/O object later (after it has been constructed). This again is something which hasn't been done yet in any Boost library (all other objects support asynchronous I/O right after construction).
I think it all comes down whether we want to treat a process like any other I/O object. While noone complains about creating I/O service objects when you use sockets I'm not sure about processes? Developers might be surprised if Boost.Process is coupled with Boost.Asio?
I'm not yet familiar with boost.asio, I'm going to dig further into it today, thanks for the idea :) Moreover, Boris, I saw you've made a recent update to the handling signals proposal in asio. I'll check this out too.