Thoughts about future releases, in no particular order.
Feel free to share your thoughts with me at  mob@cpan.org 
or through  http://rt.cpan.org/NoAuth/Bugs.html?Dist=Forks-Super

Possible TODOs:

    _x_ support sockets/pipes for cmd-style forks like IPC::Open3 does.
	_X_ for Unixy systems
	___ for MSWin32
	    IPC::Open3 supports MSWin32/os2 with the <system 1, @_>
	    construction. Don't think that is appropriate for this module.

    ___ Make Forks::Super safe(r) for unsafe signals (pre 5.7.3, see perlipc).
	Can test with  PERL_SIGNALS=unsafe make test .
	___ cygwin 5.10: occassionally failure, IPC litter
	___ linux: make test can hang
        _X_ don't know specifically what I did, but 
            PERL_SIGNALS=unsafe make test/fasttest are usually successful now,
	    at least for v0.49
	    

    _O_ Make Forks::Super usable with v5.6.
	My 5.6 test environments are getting difficult to maintain.

    ___ There's enough stuff in here now that performance is affected,
	especially when there are lots of short tasks. What can be done
	to tighten up performance? What can be done to reduce overhead
	when there are many short tasks?
	___ disable $FSJ::Ipc::USE_TIE_?H
	_X_ tightened some delays in file-based IPC

    ___ fork { run => [ \@cmd, ... ] }
	to invoke or emulate IPC::Run's rich feature set
	___ What else can I learn by studying IPC::Run?

    ___ What other key-value pairs should FSJ::read_stdxxx handle?
	_X_ warn => 0|1
	_X_ timeout => max number of seconds to wait for input
	___ I/O layers? :gz? :crlf?

    ___ The IPC module creates a temporary directory that will
        be deleted when the program ends. Is there another module that
        has solved this problem better than I did?
	_O_ File::Temp? Does this work on MSWin32?
	:-( File::Temp not robust enough when child procs outlive the parent.
	    Probably has NFS issues, too.
    ___ No complaints yet, but is there a smarter way to
        set the IPC directory?

    ___ Runtime IPC cleanup routine for long running programs. For long
	completed jobs: close the open filehandles that have slipped
	through the cracks; remove the IPC files; move from 
	%ALL_JOBS,@ALL_JOBS to %ARCHIVED_JOBS,@ARCHIVED_JOBS

    ___ Demos/examples/cookbook section.
        ___ Perform 1000's of jobs, 20 at a time
            ___ with queueing to perform other tasks
            ___ example: web crawler
	    _x_ example: multi-threaded du
        _x_ timeout long running jobs
        _x_ manipulate CPU affinities
        ___ dependencies
        ___ interactive client/server example of IPC
        _x_ see t/forked_harness.pl
        ___ load management
            ___ block while system is busy
            ___ suspend/resume
        ___ bg_eval, bg_qx examples
	    _X_ factorial.pl for bg_eval
        ___ can_launch examples
        ___ how to: use sleep with Forks::Super
        ___ how to: use alarm with Forks::Super
        ___ changing IPC_DIR
        ___ tuning Forks::Super for fast jobs, slow jobs,
	    memory intensive jobs, cpu intensive jobs,
	    I/O bound jobs
        ___ scheduler app, running for days at a time
	___ reuse
	___ share
	___ daemon

    _x_ Forks::Super::Job::dispose( @jobs ) method
        _X_ Removes entry from @ALL_JOBS, %ALL_JOBS
	   ___ move to @ARCHIVED_JOBS, %ARCHIVED_JOBS?

    ___ POSIX::RT::Timer as possible replacement for get/set itimer?

    _-_ daemonize => 1  option to close/reopen STDxxx fhs to /dev/null,
        start a new process group, change directory to /.
        Disables IPC. Set umask to 0.
	See the Wikipedia daemon article to see all the requirements.
	    _x_ Or can it? If {daemon} is true, pass grandchild pid back
                to parent and parent can reset {real_id}?
	___ how to test it?
	___ Will blanket close ruin sockethandles in the parent?
	___ Set the os_priority, cpu_affinity
	___ timeout, expiration?
	___ A daemonized job cannot be signalled with Forks::Super::kill(job)
	    _X_ Then again, couldn't a daemon use most of the options to fork(),
	        including timeout, setting {real_pid}, etc.? Suppose that at 
	        the time a daemonized job is created, we create a small pipe
		or other IPC channel for the child to tell the parent
	        what is the grandchild's PID ...
        _X_ a daemonized process can't (or at least really really shouldn't)
	    use socket/pipe IPC 
        _O_ Use Proc::Daemon if available? Any::Daemon
        ___ May not work for Win32
	    ___ Win32 with cmd, exec: need to use Win32::CreateProcess,
	        not fork()+system, fork()+exec, or fork()+Win32::CreateProcess
	_X_ daemon processes do not count against your $FS::MAX_PROC limit

    ___ how to daemonize
        _x_ look for $job->{daemon} setting
	_x_ preconfig: choose $job->{daemon_ipc} file
	_x_ after fork (child):
	    _x_ do daemon stuff
	        _x_ close all open file descriptors
		_x_ umask, chdir
	    _x_ fork again
	        in grandchild: continue
	    _x_ report child, grandchild pids to $job->{daemon_ipc}
	_x_ after fork (parent)
	    _x_ wait for $job->{daemon_ipc} channel to be ready
	    _x_ update $job->{real_pid}
	    _x_ caller should never need to know about intermediate pid?
	_x_ Sigchld::handle_SIGCHLD should not freak out when the
	    intermediate daemon process exits
	_x_ Wait::waitpid method should ignore daemon pids
        _x_ what should suspend/resume do with daemon?
	_x_ finish callback not allowed for daemon
	_x_ FS::status, FSJ::status should fail with daemon [may work OOTB]
	_x_ FS::state, FSJ::state should be special with daemon
	    _x_ FSJ::is_xxx are different
	_x_ socket/pipe IPC not allowed with daemon
	_x_ kill should work out-of-the-box, but take a closer look
	_x_ not all END{} blocks should run from daemon 
	_x_ LazyEval cannot work with daemon

    ___ make SysInfo.pm.PL capable of managing config for multiple $^O,$]?
	Or more generally, what if the installed SysInfo.pm is set up for
	a different sys/version than the one that is actually being used?
	___ Some things are cheap to determine $SYSTEM/$VERSION/
	    $NUM_PROCESSORS(?)/all of %CONFIG; Others are expensive 
	    $MAX_FORK/$MAX_OPEN_FH/$SOCKET_CAPACITY/$PIPE_CAPACITY,
	    even $SLEEP_ALARM_COMPAT is not a cost you want to pay every
	    time the module is loaded.
	_o_ Can we detect all the versions of Perl that will use a module
	    installed a specific location? And run SysInfo.pm.PL for all
	    of them? I doubt it.

    _o_ Fails t/20 t/21 on OpenBSD run as make test, but succeed as
	standalone? What's up with that? process groups?
	Intermittent failures -- probably max background process
	restrictions on my OpenBSD host.

    _X_ Forks::Super::Job can overload "<>" (iteration) operator,
	invoking $job->read_stdout(). Beware of overload bug, though:
	"Even in list context, the iterator is currently called only
	once and with scalar context."
	___ Actually, maybe it can't. Can't define even the buggy
            version of Forks::Super::Job::(<> except with some
	    crazy machinations.

    ___ test suspend/resume cycles where child has SIGSTOP/CONT handlers

    _x_ "Don't exit from child sub with socket IPC" -- can we address this?
	A child-specific END{} block in Forks/Super/Job.pm ?

    _X_ Forks::Super::Sigchld notes in a comment that dates back to v0.16
        that Cygwin might not clean up deferred jobs correctly. Is this
	still an issue? Doesn't look like it ...

    _X_ 40d problem on solaris
	___ will we ever use setitimer for timeout/expiration?

    ___ Understand why Windows hack needed for socket write (see 
	FSJ::Ipc::write_stdin, FST::IPCSocketHandle::trivial_pause).
	Is there a better solution?

    _X_ Upgrade bundles Sys::CpuAffinity to 1.01.
    ___ 1.02?

    _X_ dir => directory  option to run the child process from
	a particular directory.
	Child dies if not able to change to the specificed directory.

    _X_ umask => 0123 option?

    _X_ allow cpu_affinity => [ @list ] style

    ___ 0.51 test failures. I don't think any of these are
        reliably reproducible
	_x_ timeout takes 10000s in FreeBSD
	    suppress return from SIGALRM handler
	_x_ 25#15-17 on loaded Linux 5.14.0
	    wait longer for child feedback
	_o_ 40i#2 problem on Linux (x3)
	    was elapsed time too high (>7s) or too low (<4s)? Can't tell.
	_x_ 42g#17-18 on loaded Linux 5.14.0
	    wait longer to receive STDOUT
	___ 43d exit 13 on Linux (SIGPIPE)
	_o_ 44a#7-12 on MSWin32
	___ 24 exit 2 on MSWin32 (SIGINT),
	    47 exit 15 on MSWin32 (SIGTERM),
	    48 exit 23 on MSWin32 (SIGSTOP)
	___ 49#4 on Linux
	___ 49#5,8 on MSWin32
	_o_ 54#10 on Linux
	___ break 49 up?

    ___ Does anything bad happen when you set $SIG{CHLD} = 'IGNORE' ?
        'DEFAULT'? sub {} ? undef ?
        _X_ Yes. ANY setting for $SIG{CHLD} will let system calls
	    like  sleep  get interrupted by SIGCHLD events.
	    See t/31

	    It's curious that we can assign to $XSIG{CHLD}[-1]
	    (which does set a handler for SIGCHLD) but that DOESN'T
	    trigger interruption of system calls. It's as if perl
            is just checking  defined $SIG{CHLD}  instead of whether
	    an actual signal handler is registered to decide whether
	    to interrupt sleep.

        ___ Actually, this would be part of a good XSIG framework workout.
            Some scripts with natural forks and wait/waitpid calls
            should produce the same results with and without Forks::Super
            (i.e., F::S is a drop-in replacement)

    ___ Prior to v0.52, bg_eval and bg_qx could be called in list context
        but they wouldn't return control to foreground process. Can this
	be fixed?

    ___ is _trap_signals call in FSJ::Ipc::_config_fh_parent necessary?

    _X_ FSJ::Ipc::_close, _close_socket: no warnings pragmas are too strong.
        _o_ untie attempted while 2 inner refs exist ... 2065 [untie]
	_X_ use of uninit value in numeric ge (>=)  2084 [uninitialized]
        _X_ use of uninit value in bitwise and (&)  2087 [uninitialized]

    _X_ $F::S::CHILD_FORK_OK>0 -- not tested ...
        _X_ -1: fork from "child" fails
	_X_ +1: fork from child exactly once
	_X_ +0.5: FSfork from child, CORE fork from grandchildren
	_X_ +2: FSfork from child and grandchild only
	_X_ +1.5: FSfork from child,grandchild CORE fork after that
	_X_ +3: FSfork from 3 generations

    ___ Implement, test respect block/timeout in IPCPipeHandle

    ___ Track down, solve 'untie attempted while ... inner references'
        mystery with FST::IPCFileHandle
	___ some progress, down to one reference

    ___ Forks::Super::Tie::BackgroundScalar is no longer used with 'tie'
        (since v0.43). Change the name? 

    _X_ fork { env => \%hash }  to set the environment of the child
        process when the job is launched.
	_X_ test

    ___ test for -MForks::Super=cleanse, -MForks::Super=cleanse,dir

    ___ 0.52 test failures:
        ___ MSWin32 24#2; 47#15; 48#23; 49#5,8
	___ FreeBSD child still fails to timeout

    ___ INET sockets as well as UNIX sockets, if you can commit to a port
        before fork'ing and not bind to it until after fork'ing.

    _X_ kill on fork to cmd? Want to signal the subprocess (running in "system")
        not the direct child process, especially for suspend
	_X_ on style eq 'cmd', set {signal_ipc} for child to communicate
            grandchild proc to the parent. On kill, parent read {signal_pid}
	    attribute from {signal_ipc} file.
	fork to exec should be ok ...

    ___ daemon tests:
        _X_ daemon should survive after calling process exits
	___ file IPC is still allowed with daemons, test it

    ___ refactoring needed after getting daemon code to work.
        ___ handle failures

    ___ reinstate t/31? ok on Cygwin, MSWin32, Linux, FreeBSD ... 

    ___ is it feasible to fork to a "process pool" (cf. FastCGI)?
        There could be significant improvement for use cases with
        lots of short jobs.

    ___ TASKKILL, TASKLIST are strongly recommended utilities to have
        for MSWin32. Should we try harder to find them in the PATH?

    ___ We test for job state eq 'DAEMON-COMPLETE', but we don't actually
        set it anywhere yet

    ___ When $SIG{CHLD}='IGNORE', calling  wait  or  waitpid  NEVER returns
        a pid, it's always either 0 or -1. See t/drop-in-replacement.pl
        Should  Forks::Super  check the value of $SIG{CHLD} and emulate
	this behavior?

    _X_ http://stackoverflow.com/questions/6574722/. Implement

            fork { share => [ \$scalar, \@list, \%hash ] }

        where the variable contents are copied to the parent when
	the child is finished.

    ___ Test file just for Forks::Super::Job
        ___ and for Forks::Super::Queue, Forks::Super::Wait

    ___ Forks::Super::kill to accept arbitrary process ids

    _x_ Signalling on Windows. Can we make the Unix-y signal emulation
        in Forks::Super::kill more faithful? 

    ___ Currently, 'kill' to a fork-to