93.1.19: {\tt (WAIT-WITH-TIMEOUT $\ldots$)} returns \lisptrue{} if
wait ends when condition is true, \lispfalse{} if wait ends with timeout.

92.9.8: New construct {\tt (EVAP-PROTECT {\it doit ---followups---})}:
Like {\tt SEQ}, but even if the task for {\it doit\/} evaporates, the
followups will occur.  Two subtasks, with name-prefixes {\tt (DOIT)}
and {\tt (FOLLOWUP)}.  If the followups' execution terminates after
the doit task has evaporated, then the value of the followups is
ignored; if the followups should fail, the failure will be ignored.

If the followups never terminate, the management takes no
responsibility for the ensuing carnage and destruction.

92.3.31: Processes are no longer glued so tightly
to the task hierarchy.  You can now do a {\tt VALVE-REQUEST} or
{\tt VALVE-RELEASE} for an arbitrary process, not just the one you're in.
(Yes, one process can tap another on the shoulder and declare that it
asked for a valve; if the valve is in use, the other process hangs!)

Even better:

\items
\cleartabs
\+\hskip 1cm& {\tt (PROCESS-IN {\it proc ---body---})}  and \cr
\+	&{\tt (PROCESS-OUT {\it proc ---body---})}\cr
\enditems

allow you to control which process the task for -body- is attached to.
{\tt PROCESS-IN} causes you to be inside proc.  {\tt PROCESS-OUT} puts you
outside proc (in the nearest enclosing superproc).  Neither alters the
process hierarchy in any way; it remains a tree, and each process is
associated with a task.  What has changed is that subtasks of $T$ do not
have to include the same processes as $T$ itself. 

None of this should affect old code.  It's very useful in writing
policies that need to put part of themselves outside the valve
requests made by their primaries.

[Greg Hager has pointed out that "monitor" might be a better word than
"process" for the rpl construct.]

92.3.1: {\tt (LOCAL-TAGS ({\it ---labels---}) {\it ---body---})}: Equivalent
to {\it body\/} alone, except that if any element of {\it labels\/} occurs
as a tag in {\it body,} it gets bound as a variable local to the body,
and does not get passed to the nearest enclosing generative context.
This is handy for macros that want to expand to constructs with
standard tags.

{\tt (COPE-WITH-OCCURRENCES {\it fluent} {\it ---body---})}: A macro
that expands to {\tt (LOOP (WAIT-FOR {\it fluent}) {\it ---body---})}.
It's like {\tt WHENEVER}, except that, once {\it fluent} has become true,
further changes in the {\it fluent} are ignored until the {\it body}
has finished, modulo occurrences of {\tt NEXT-ITERATION} in the {\it body}.
{\tt (WHENEVER $p$ {\it ---body---})} could almost have been defined as {\tt
(COPE-WITH-OCCURRENCES $p$ NEXT-ITERATION {\it ---body---})}.

92.2.24: In a {\tt PLAN}, the earlier policies take priority over the later
ones.

In general, the manual does not make it clear just how absolute is the
priority policies have over their primary tasks.  If a policy requests
a valve, it is always able to pre-empt it from the primary.  


91.12.15: Some of the functionality of {\tt TOP-LEVEL} has been
separated out.  {\tt (PLANNER-REPORT {\it id} {\it cmd})} executes
{\it cmd} (as subtask with path prefix {\tt (REPORTED-ACT)}).  When
{\it cmd} succeeds or fails, then {\tt AGENT-REPORT*} is called.  (See
the description of {\tt TOP-LEVEL} in the manual.)  

