One example of stochastic behavior...

You reinvented a fork bomb. Except on windows, fork actually spawns a thread; so it might better be termed a thread-bomb in this case.

Try feeding this:  :(){ :|:& };: to bash on a *nix system and see how deterministic the DoS is.

You are also asking the child 'process' to kill its parent 'process'; but on windows they are actually just threads within the same process. Ie. You are attempting to kill your own process. In addition, you are also thread-bombing the system from within that same process. Is there any wonder that the process may not respond to the request in a predictable manner?

And you are using a random delay -- sleep 0 equates to "relinquish the rest of the current timeslice" which is an unknowable quantum of time, that could range from 0 microseconds -- if the timeslice was about to end anyway; or if there are no other processes in the system immediately eligible to run -- to N * q where N is the number of other processes and threads in the system that are eligible to run; and q is the scheduler quantum which can vary from ~5 to ~180 microseconds depending upon: a) the version of Windows; b) how that version is configured (workstation or server; foreground or background priority); c) a whole bunch of other factors.

In other words; you have programmed a random delay into your program as surely as if you had written Win32::Sleep( rand()*100 ).

Of course the behaviour is "stochastic"; That's how you programmed it to be!

Could you accept (or even recommend) the addition of something like this:

Neither!

I use kill (on windows) to good effect all the time. The difference is that I have spent enough time to understand the limitations of the emulation on my platform. I understand that they give me a fairly crude interface to the native Console control handler functionality from Perl; and that -- used carefully -- can provide functionality that I might otherwise have to dip into Inline::C or XS to gain access to.

What I would say; and have said many times; is do not attempt to use fork & the windows signals emulation to try to port *nix idioms to windows; because you will be sadly let down.

The basic problem here is the entire attempt to make Windows look like or work like some variant of *nix. It is simply far easier to write two scripts -- one for each platform -- than to try and construct and maintain one that will operate correctly on both platforms.