2) BTW, I'd just bundle Net::Ping::External in with Net::Ping so they are installed together (though making Net::Ping robust in the face of no Net::Ping::External is still a good idea).

4) As I mention in Net::Ping, the mini series, non-blocking connect not working is simply a bug in WinSock (both 1 and 2). You can use the non-standard Async* APIs to do non-blocking "connect" under Win32, but using Win32::CreateProcess is going to be a lot less work so that is the way I would go for Win32. Switching from alarm to non-blocking connect makes sense for Unixy systems. And no, the Perl Socket modules don't support connect timeouts under Win32 (they detect that alarm is not supported and silently disable the timeout for connect).

5) Yes, I like the idea of Net::Ping::Parallel but suspect that the code and API will be so similar between Net::Ping and Net::Ping::Parallel, that it makes sense to have them rather tightly interconnected. For example, it might work to teach Net::Ping to support an asynchronous API that Net::Ping::Parallel uses. In the end, whether these are independant modules, interconnected modules, two module that use a third, lower-level module, or even just two name spaces handled by a single module depends on the grimy details when you get to implementing them.