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.

    ___ 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? need to benchmark
	_X_ tightened some delays in file-based IPC
        ___ shorten $Forks::Super::Queue::QUEUE_MONITOR_FREQ

    ___ 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
        ___ log => 0|1|*handle|\@list?

    _x_ I/O layers in ? :gz? :crlf?
    	_X_ put IO layers in the  child_fh  spec
	    _x_ will this work for sockets? [Yeah, sort of, for some layers]

    ___ No complaints yet, but is there a smarter way to
        set the IPC directory?
    ___ Refactor how we create and remove the temp 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
        ___ run a server using Forks::Super
        _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 that can run 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}?
	_X_ how to test it?
	___ Will blanket close ruin sockethandles in the parent?
	_x_ Set the os_priority, cpu_affinity
	_x_ timeout, expiration?
	_x_ 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
	    _X_ Win32 with cmd, exec: need to use Win32::CreateProcess,
	        not fork()+system, fork()+exec, or fork()+Win32::CreateProcess
            ___ system 1,... creates new process but does not allow the 
                parent program to exit until that new process completes.
                maybe we want to create a wrapper program to use with
                Win32 (and maybe other) processes ... see below
	_X_ daemon processes do not count against your $FS::MAX_PROC limit

    _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.

    _X_ test suspend/resume cycles where child has SIGSTOP handlers
        it should not be possible to trap these signals.
        (It turns out SIGCONT can be trapped)

    ___ 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.
    _x_ <XXX>1.02? 1.03?</XXX> 1.04

    ___ 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.

        ___ Yes again. 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 (actually, this is platform dependent).
 	    ___ Should  Forks::Super  check the value of $SIG{CHLD}
	        and emulate this behavior?

        ___ 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_ Implement, test respect block/timeout in IPCPipeHandle
        _X_ works, though maybe could be refactored

    ___ 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? 

    ___ test for -MForks::Super=cleanse, -MForks::Super=cleanse,dir
    ___ test normal and abnormal IPC cleanup

    ___ 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. Leave this for 1.0?

    ___ 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

    _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::Wait
	_X_ Forks::Super::Util
        _X_ Forks::Super::Queue

    _X_ Forks::Super::kill to accept arbitrary process ids, not just pids
        that Forks::Super is keeping explicit track of

    ___ Currently, 'kill' to a fork-to-cmd or fork-to-exec might signal
        two separate processes. Can we coerce kill to return 1 in this
	case instead of 2? Currently it is a big incompatibility between
	this module and core use.

    ___ a "wrapper" script that executes an arbitrary command in a
        separate process, but as if it had come from a fork call within
        a program using Forks::Super. The purpose is to make sure that
        a program runs in a detached process. The wrapper will set up
        all the (almost surely file based) IPC and then run the desired
        program.

    ___ backport to 5.6
        _x_ Signals/XSIG needs work
        _x_ Cwd 2.04 not effective in Forks::Super::Util::abs_path?
            No, it's just Cwd::abs_path that's not effective.
        ___ unsafe signals leave zombies, make trouble
        ___ any pipe code causes SIGSEGV
        _X_ :utf8 layer not available for IO layers test
	    skip those tests
        _X_ even the :crlf layer behaves differently on 56
            skip/adjust those tests

    ___ share MAX_PROC across processes, or have a SHARED_MAX_PROC
        attribute to limit the number of processes across a group
	of parent processes using Forks::Super.
 	___ defer to 1.0?
	___ and the dual of this problem -- manage multiple 
	    processes on separate remote hosts from a single
	    process (i.e., use Forks::Super to manage a grid?)

    ___ are %CHILD_STDxxx variables obsolete? How to deprecate?

    ___ setuid =>  option to fork

    ___ test needs: daemon+os_priority, cpu_affinity
        daemon+name? daemon+delay, daemon+depend

    ___ Make forked_harness.pl an application that gets installed
        with Forks::Super
        _X_ put pod in t/forked_harness.pl

    _X_ suspend / resume broken on Cygwin?
        _X_ maybe we should use the Win32 api functions instead of builtin kill

    ___ daemon support depends on file-based IPC?
        make a socket-based alternative. Let $job->{signal_ipc}, {daemon_ipc}
	be sockets?

    ___ FSJ::OS::Win32::signal_procs: is process group applied inconsistently?

    ___ Use FSJ::OS::totally_kludgy_process_monitor as a workaround to
        timeout + exec  incompatibility

    ___ pause use -- in some cases, we would wan't pause() to return
        if a child completes in the middle of the pause statement.
	This applies especially to the pause() calls in Forks::Super::Wait.
	If we could do that, then we wouldn't have to be afraid to set
	$Forks::Super::Util::DEFAULT_PAUSE to a high value for problems
	with long running jobs.

	For pause() calls inside FSJ::Ipc::_readline_XXX, the length of
	the pause should be tuned to the output frequency of the child,
	which will be different from the expected runtime of the child.

    ___ change expressions like  if (ref($obj) eq 'Forks::Super::Job')
        to something more portable -- if ($obj->isa('Forks::Super::Job') ? 
        The latter is more flexible and lets  Forks::Super::Job  be subclassed
	by us and others without breaking anything.

    ___ Test::More::ok variant that can be made more lenient, for "timing"
        tests that aren't that important under stress testing.