That is, a way to abandon the current action(s) and begin command
processing all over again with a new input. The activity "after reading a
player's command" is already capable of modifying the command text, but
that happens before the command is converted into an action, and well
before action processing starts. So at present, something like this is
impossible:

Instead of taking a candle, reparse the player's command as "get lamp".

For instance, in an extension to deal with new player input, you might have
determined that a player has used a recognized noun and a recognized verb,
but in the wrong order; you could make adjustments and try reparsing the
command to see if that makes sense.

I think I briefly mentioned this a long time ago, but given the news
that closures will be added in a future version, I think it ought to
be restated in depth: I propose adding an NI feature to facilitate
writing "to decide which description is..." phrases, by translating
the phrase body into a state machine implementation based around a
closure.

(Caution: long technical discussion follows, some based on speculation
about I7 features yet to come. For now, this is just something to
think about, and possibly -- I hope -- refer back to some time after
this upcoming release.)

This proposal mirrors a feature found in Python and C#, where you can
use the "yield" keyword while *writing* a function to (in effect)
return a sequence of values, but when *calling* the function, the
return value is actually a collection which you can access using the
languages' collection iteration statements. For example, this C# code
prints the first 100 Fibonacci numbers:

IEnumerable<int> Fibonacci()
{
int a = 0, b = 1;
for (int i = 0; i < 100; i++) {
yield return b;
int t = a + b;
a = b;
b = t;
}
}

void Main()
{
foreach (int x in Fibonacci())
Console.WriteLine(x);
}

Conceptually, the Fibonacci() function pauses after it yields each
value, then resumes when "foreach" requests the next value. The
implementation actually involves the compiler rewriting Fibonacci() to
return an instance of a newly created class, and moving its local
variables and code into that class. The code is massaged to become a
state machine: each "yield" statement stores the value to be yielded
and updates the state variable (one state per yield statement), and at
the beginning of the code is inserted a switch block that uses the
state variable to jump to the point after the corresponding yield
statement. (Note that since Fibonacci() produces its values lazily,
rather than all at once, the sequence could just as well be infinite,
resulting in a program that kept printing numbers forever.)

Inform 7 code to produce the same sequence might look like this:

To decide which description of numbers is the Fibonacci sequence:
let A be 0;
let B be 1;
repeat with I running from 1 to 100:
yield B;
let T be A + B;
let A be B;
let B be T.

But of course the interesting part is how it would be implemented.
There are two parts to this: first, the phrase must be rewritten as a
state machine (with local variables in an array or on the heap, rather
than the VM stack), and second, the phrase must be embedded into a
description routine. Rewriting the phrase is straightforward, since
closures will already require translating local variable access into
array/heap access:

! I don't know how closure storage will work,
! but perhaps something like this...

! block to store local values and state
Array fib_storage --> 6;

! local variable offsets within block
Constant FIB_STATE = 0;
Constant FIB_RESULT = 1;
Constant FIB_A = 2;
Constant FIB_B = 3;
Constant FIB_I = 4;
Constant FIB_T = 5;

! rewrite the phrase as a state machine
[ PHR_Fibonacci;
switch (fib_storage-->FIB_STATE)
{
0: jump State0;
1: jump State1;
2: jump State2;
}

! start of phrase body
.State0;
! [let A be 0]
fib_storage-->FIB_A = 0;
! [let B be 1]
fib_storage-->FIB_B = 1;
! [repeat with I running from 1 to 100]
for (fib_storage-->FIB_I = 1:
fib_storage-->FIB_I <= 100:
(fib_storage-->FIB_I)++)
{
! [yield B]
fib_storage-->FIB_RESULT = fib_storage-->FIB_B;
fib_storage-->FIB_STATE = 1;
rtrue; ! yielded a value

! resume here upon next call
.State1;

! [let T be A + B]
fib_storage-->FIB_T = fib_storage-->FIB_A + fib_storage-->FIB_B;
! [let A be B]
fib_storage-->FIB_A = fib_storage-->FIB_B;
! [let B be T]
fib_storage-->FIB_B = fib_storage-->FIB_T;
}

! end of phrase body
fib_storage-->FIB_STATE = 2;
.State2;
rfalse; ! did not yield a value
];

More complicated, perhaps, is how to turn this into a description
routine. Description routines must be able to perform several
operations on the set of described values: (1) find the member with
the highest/lowest value for a given property, (2) find the sum of all
members' values for a given property, (3) find a random member, (4)
count the number of members, (5) find the first or next member in
sequence, and (6) test whether a given value is a member.

Operations #1-4 are all currently implemented as variations on the
same theme: loop through the entire set (twice for #3) and optionally
do something with each member; operation #6 could also be done this
way, although it currently isn't. This is easily implemented in terms
of PHR_Fibonacci. For example, to count the number of members:

! reset state machine
fib_storage-->FIB_STATE = 0;
! loop through all members and count
while (PHR_Fibonacci())
counter++;
return counter;

That leaves operation #5, which is simple if multiple simultaneous
loops through the sequence are disallowed, and a bit more complicated
if they're allowed. The simple way:

! maybe reset state machine
if (x_ix == 0 || x == 0)
fib_storage-->FIB_STATE = 0;
! return the next member
if (PHR_Fibonacci())
return fib_storage-->FIB_RESULT;
else
return nothing;

The translated routine already knows how to pick up where it left off,
so we just leave its state alone when we're finding subsequent
members.

But to support multiple simultaneous loops, things need to be a little
more complicated: "fib_storage" needs to be a parameter passed in by
the calling routine, so each loop has its own copy of the closure
state. Since the caller doesn't know the implementation details of the
description it's looping over, that means the description routine
needs to allocate the storage block: the description routine spec must
be expanded to let the routine return a pointer to that block before
the loop starts, and then to deallocate it after the loop ends.

I've attempted to write this as an extension, and the state machine
translation itself is easy enough, but I've run into some serious
obstacles: basically, due to the limited information available at
I6-compile-time, an embarrassing amount of low-level,
platform-specific hackery is required for saving local variable values
(and even that doesn't work when block-type variables are involved);
turning the state machine into a description routine would also
require building a routine on the heap, which never feels like the
right thing to do.

Similar to the "the only ..." request, I propose a "the first... " phrase.

There are times when all you care about is finding something that matches the description. "A random" will on average iterate through all the things of the kind 1.5 times. With "the first" it could stop as soon as it finds something that matches.

This would be useful: for cloning objects with Dynamic Objects.
Exhaustively processing a list when the processing will alter the list. In flexible windows I do:

while the number of g-unrequired g-present childless g-windows > 0:
repeat with h running through g-unrequired g-present childless g-windows:
g-destroy h;

https://github.com/i7/extensions/blob/3ebc0c/Jon%20Ingold/Flexible%20Windows.i7x#L225

With "the first" it could be changed to:

while the first g-unrequired g-present childless g-windows is not nothing:
repeat with h running through g-unrequired g-present childless g-windows:
g-destroy h;

Which would be somewhat faster. :)

Would it be possible to make the printing of a room’s name (in bold, at the top of a room description) into an activity? –Or, perhaps more usefully, make the entire process of “printing a room description” an activity.
 
I’ve often found myself wishing that I could refer to the printing of a room description as the context for printing a room’s name. Specifically, it would be nice to be able to create a rule for printing the name of a room that capitalizes it when printing a room description or constructing the status line, but not under other circumstances (Such as reporting that “Hans arrives from the kitchen.”).

"My suggestion would be to abolish 'carried' in action specifications (as in Eating is an action applying to one carried thing) and replace the carrying requirements rule with a new rulebook that's responsible for all implicit actions (including the existing implicit takes). This would make it easy to unlist an implicit action rule an author doesn't like or doesn't need and replace it with one s/he prefers. For example, instead of way the implicit take for eating currently works, an author would be able to write:

implicit action for eating a portable edible thing:
   carry out the implicitly taking activity with the noun;
   if the noun is not carried, stop the action.

So that we'd only see "(first taking the whatever)" if the action
had some prospect of success."