Although this adds nothing that cannot already be done, given the disconnect between establishing the return context at thread creation time, and its effect at thread join time, I do see the motivation behind wanting to make that context more explicit.

I do have to wonder at the need for two separate interfaces though?

thread->create( { context => 'list' }, ...
# -v-
thread->create( { list => 1 }, ...
[download]

The latter seems entirely redundant, and also wrong.

1. This is a single option with 3 possibilities--not 3 binary options.
2. It adds complexity where none is necessary or desirable.

   What context results from this?

   threads->create( { scalar => 1, void => 1, context => list, list => 0 
   +}, ...
   [download]

3. My main objection is the effect on performance.

   One of the main use of the return values/context is going to be applications that use the spawn & die mode of operation. Short lived threads that do something, return the results to the parent and exit. Spawn another for the next task. A typical example might be a threaded server.

   For this kind of application, the time taken for the spawning thread to start a thread and get back to deal with the next incoming connection is critical to the overall performance. Once a connection has been accepted, the time between the accept and the first read is not critical, but delays in getting back to service the next accept are.

   The additional complexity of parsing and validating the dual interface comes at a critical point in those applications that are most likely to make most use of them.