it may just be the way STDERR/OUT is handled on my system

Another possibility. And one that is both far easier to understand and also nicely attributable to 'user error' rather than a serious internals bug.

That said, I did consider the possibility that there was some kind of interleavcing of threaded output at play here, but it is very hard to see how that could give rise to this output:

2$VAR1 = {
          'a' => {}
        };
1$VAR1 = {
          'a' => {},
          'b' => {},
          'a' => {},
          'b' => {}
        };
[download]

Not only would the output from thread 2 have to be delivered to the screen out of order--the close brace appearing before the 'b' pair--the 'a' pair from thread 1 would have to be delayed, interleaved and duplicated, and I find it impossible to dream up the scenario where the absence of resource locks could produce that effect.

You could certainly try using the tprint() sub I posted earlier in the thread (or rolling your own), but I wouldn't hold any great expectation of it providing a fix.

Then again, I cannot reproduce the problem here even if I bypass the ouput serialisation my OS does when writing to the screen, by redirecting the putput to a file. 5.8.6 or 5.10.0, I always get the same correct output. If I remove the sleeps from teh threadproc, I can indice some variablility, but nothing untoward or unexplainable.

This certainly seems to be a platform (or perhaps complier/CRT) specific problem.