|There's more than one way to do things|
I'll respond point-by-point as well.
1. No response needed. ;)
2. Perhaps the user would specify, through a method, which command-line to run as the system ping utility. Future pings that needed the "system" mode would run the appropriate program. I do agree that just arbitrarily allowing any user to merely call `ping` without thinking about it first is up for trouble. The point regarding not attempting to circumvent ICMP restrictions is taken.
3.Perhaps I was unclear here. Only one attempt to ping the remote computer would be used. What I'm intending here is to first try doing a normal ICMP ping; if the system disallows ICMP, we fallback to TCP or the system's ping command. I agree that perhaps this functionality should not be built directly into Net::Ping, but a new Net::Ping::Extras module (insert a better name here if you like) that extends Net::Ping with more functionality (AKA code bloat).
4. alarm() is already used in the current Net::Ping code. I'd be attempting to remove the current usage of alarm() from the module. So I'm assuming you'd be okay with this change?
5. I agree this functionality constitutes code bloat, too, and I agree that it probably shouldn't be stuck in Net::Ping. It is something I would want to add to a new module (i.e. Net::Ping::Extras). The point of the $num_forks option is to only use as many forks as the user desires -- I don't see any need to fork off 20 processes, unless your script were trying to repeatedly ping a thousand hosts.
What do you think of this newly-modified proposal?