The following are some implementation suggestions.
Christopher Diggins (http://lists.boost.org/MailArchives/boost/msg79255.php) suggested that it would be nice if operator< and operator> were available to redirect the standard input and the standard output streams to any other iostream. This is specially interesting as it simplifies the execution syntax. It'd also be nice if it was possible to automatically construct pipelines by using an operator, such as operator|.
However, the same person also said (http://lists.boost.org/MailArchives/boost/msg79372.php) that using three different operators (<, >, |) to express these constructions is not such a good idea. For the shell, it's unavoidable, because it's non-typed. But with a strongly typed language, such as C++, it makes no sense. Furthermore, the syntax can become ambiguous and/or difficult to understand.
As regards the operator to be used, there are multiple possibilities, such as >, | or >> (among other possibilities). The last one may seem a good choice (and it looked like to me), but it's not, because it can become confusing (see http://lists.boost.org/MailArchives/boost/msg79413.php by Jonathan Wakely). Therefore, | seems like the best possibility, not because > is bad, but because it's what people uses in the shell and clearly expresses the concept of a "pipeline".
Configuring and running the process using a single string, just like the system(3) call does is dangerous. The code has to interpret spaces, quoting and many other details that can easily lead to mistakes. It'd be better if the class interface had multiple methods to set up everything (executable, arguments, redirections, etc.)
In words of Aaron W. LaFramboise? (http://lists.boost.org/MailArchives/boost/msg79252.php): it is extremely important that the interface does not hide features of the underlying OS interface, as is vogue for many irresponsible "frameworks". For example, if the OS allows processes to be suspended, but the basic interface does not because not all popular OSes possess this ability, the library must make provisions for a user to be able to access this ability through some sort of extension. This may mean an implementation that uses runtime polymorphism rather than concrete types.
Also suggested by Aaron W. LaFramboise? (http://lists.boost.org/MailArchives/boost/msg79252.php): The library has to be aware of blocking operations. It is often forgotten that process-spawning code is blocking code due to its interaction with the filesystem. A black-box interface that might arbitrary block for a long time, without giving the user proper indication that this may happen, is unacceptable.