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

There are several kinds of parser error that are hard to edit through the rules for printing a parser error because they rely on information buried inside the I6 code. In particular, it is difficult to reproduce or modify "The foo is empty." replies in response to GET ALL FROM FOO. It would be nice if information about what action we think we were attempting were more exposed, at least so far as to allow the I7 author to override the various cases recognized by the I6 code.

When this is done, the example "Kiwi" should be revised to use the new system so that it does not print "The high shelf is empty."

(Andrew Plotkin observes it's possible to get this out of the existing system with

To decide what action-name is the action-to-be: (- action_to_be -).

Rule for printing a parser error when the parser error is can't use
multiple objects:
if the action-to-be is the pulling action: [...] )

)

Currently you can define constants only for kinds of value in Inform 7. You can define variables and objects with the "translates into I6" syntax, but you can't use that to define them with a I6 constants. Well variables can, but they're not treated as constants in I7, and you can't use them in tables for example. You can't define an object constant by the translates syntax because you'll get an I6 error about using the name twice. It would be useful to be able to bring an I6 constant into I7, especially if it's not limited to kinds of value only.

Use a smaller type size (more similar to the comment size) for tables. (Alternatively, make the table font/size configurable so that users can customize them as the Mac IDE allows with other kinds of text.) Smaller table text would allow more text on the "page" before it wraps and the table becomes impossible to read. This would continue the move toward greater readability that was advanced by the (very nice) auto-tabbing feature in the last build. This also has the advantage from an "ideological" standpoint, since it mirrors the traditional practice in books of setting tables in a different font and/or size.

A new law that sorts rules based on the kind of objects specified after 'when' could be applied when the rules are otherwise equally specific.

Color is a kind of thing.
Blue is a color.
Red is a color.
The current color is a thing that varies;

Frobbing is an action applying to nothing. Understand "frob" as frobbing.

Place is a room.
The current color is Blue.

Instead of frobbing when the current color is something:
say "Thing!".
Instead of frobbing when the current color is a color:
say "Color!".
Instead of frobbing when the current color is blue:
say "Blue!".

Test me with "frob".

To a reader, the rule 'Instead of frobbing when the current color is something' is less specific than the others, but under the current laws all rules are considered equivalent and are listed in the order declared.