While we do not object to your suggestions, the reason we put it in place the restriction is that like you many users were bitten by the runtime violation which would force them to run in multithreaded mode just because of this library. So they had to either eat the bullet or drop their process usage. Now, instead of being bitten at runtime, they will know immediately instead of waiting execution to realize they have to run in multithreaded mode to use the process library.

To help us understand why the switch to the base process library is not ideal, we would need to know more about your alternate route. Could you tell us what replacement do you use when you are not using multithreading? Also if you are using redirections, what do you use instead when not in mulithreaded mode?

Below is not a reply but more background on this issue and what we are currently doing to address it:
<<
The main difference between the base and full process library is redirection because it is using threads to perform non-blocking input/output redirections. This also forces our users to make sure that their agent can execute in a different thread context. This is not easy and we have seen many mistakes in the past especially with Vision2.

We are currently working at providing a blocking input/output redirections facility in the base process library. It won't be perfect but should be good enough for most of our internal usages and hopefully our users too which is start, read all the input, exit.

Finally we want to make a version of the full process library that works with SCOOP too and we are still in the early stage.
>>