Requesting critique of spec of my new MayLoad utility (similar to Unix 'make')

In conjunction with my ProxHash R&D project,
in late April I started work on a new dataflow automatic-updater
utilty which is somewhat like the Unix 'make' utility.

Background: Unix's 'make' uses a list of dependencies between various
disk files to automatically update a final output file such as an
executable. Typical use is to make sure each source file is compiled
to yield a more recent compiled file, and to make sure each
executable file is at least as recent as all compiled modules it's
built from. The Java's 'ant' utility goes further to sup****t
updating of JAR files containing Class files in a similar manner.

But each of those utilities works *only* in using dependencies
between various disk files, and each effectively runs like a shell
script, starting a new utility (compiler, loader, JAR updater) for
each step in the dataflow that needs to be re-done.

New: My new utility 2008-4-MayLoad.lisp checks dependencies between
both disk files and in-memory data values (in a Lisp environment),
relating in-memory data values with the precursor data needed to
compute them and/or disk files used to back them up to avoid
time-consuming re-calculation. It does all its work from within
that single Lisp environment, not needing to start up any other
executables.

The first draft of my description of the algorithms is here:
  <http://www.rawbw.com/~rem/NewPub/MayLoadSpec.txt>
I'm soliciting feedback in two areas:
- Any obvious flaws in the algorithms, especially where I claim
   that some fact is "provably true". Can you produce any
   counterexample? Based on the described algorithms, can you find
   any case where any value is unnecessarily re-calculated or
   re-loaded or re-saved?
- Any suggested changes in wording to make the description easier
   to understand without changing the meaning.

Also I'm curious whether anybody else has already written a utility
like this, and if not I'm curious whether anybody likes my idea and
might have a practical use for it and would like to beta-test it
later when the code is more stable.