Make the template layer available for browsing from within the IDE. Minimally, this might mean making the Reserved extensions folder available from within the Extensions menu (probably with a different name, e.g. Templates). More useful would be an Index pane or special documentation page listing the templates and the order in which they are compiled (if this is straightforward). Links from this index could take us to the i6t file and to each template file's documentation (i.e. the docs currently available only in the Appendix A and B pdfs). If the goal is to hide the template layer from most users, perhaps an option in the preferences would be appropriate?

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.

Names of kinds of values can grow to arbitrary length, and it can become tiresome to type them out over and over when working with code that makes heavy use of some particular complex KOV. Therefore, being able to introduce shorter aliases would be useful. It could look something like this:

A sequence transform denotes a phrase list of numbers -> list of numbers.
A number grid denotes a list of lists of numbers.

That's a fairly simple macro system. Slightly more useful would be if we could make generic aliases:

A sequence denotes a list of numbers.
A K transform denotes a phrase K -> K.
A K grid denotes a list of lists of K.

The only complication I can see is that we might need a way to specify plural forms as well. That could perhaps be done as a parenthetical remark after the singular form.

More flexibility in how the parser copes with object names given
the instruction to "Understand the foo property as describing a bar", where
foo contains an enumerated kind of value. At present this only allows the
property to be given at the beginning of the object name, like an English
adjective. This is fine for colours and temperatures, but fails in some
other cases, for example a "can of cola" or "glass of lemonade" where cola
and lemonade are elements of a "flavour" kind of value.

One approach is to make flavor a kind of thing instead, and use a relation
to parse the name: "can of [something related by flavoring]". However, this
way we lose the other effect of the understand-property-as-describing
syntax, which is distinguishing identical objects. Cans filled with
different flavors will be collapsed into a single inventory listing, and
the parser will arbitrarily choose one rather than disambiguating, even
though they can be distinguished by typing.

The proposer suggested four possible improvements in this area:

(1) Allow the understood property value to appear anywhere in the
object name, not just at the beginning.

(2) Add an activity, or some other mechanism, for customizing the way
objects are distinguished. Running an activity for every call to
Identical() could be a performance problem, but it might be enough
simply to add a way to tell Inform that members of kind K are
distinguished by properties P and Q, even when those properties can't
or shouldn't be parsed as part of the object name.

(3) Allow the "[something related by X]" syntax to work with relations
between objects and values, not just between objects.

(4) Allow the understand-property-as-describing syntax to work with
object properties, not just values.

(3) and (4) seem entirely reasonable. With (2), the performance problems
are indeed horrible in general, but the issue here seems to be to
distinguish objects related to different things, and it may just be that
Inform needs to compile cleverer "parse_name" routines. (1) is something we
are very reluctant to do, again for run-time speed reasons, but also
because it would make object name parsing much more ambiguous and
complicated. To sum up, we accept the general point that something needs
to be done here, and will experiment.

A general observation: it seems that parsing involves a lot of list
building & modification. There's a list of items in scope, a list of
player-selected items that need disambiguating between, and the
multiple-object list containing all items selected by the player.
That's at least three lists, and ideally each of them may need
authorial tinkering: adding an item here, removing an item there,
printing the contents for debugging, fiddling with the results of an
ALL, etc. And then Jon has apparently found about three subspecies
of disambiguation, creating a dedicated rulebook for each in his
extension; I still can't keep them all straight in my head or even if
they work on the same list or not.
This may be more of a documentation request than anything, but can we
officially recognize or support this pattern? Consistent handling at
the author's code level is of course wonderful, but I at least believe
it would help us if the manual's Understand chapter specifically
illuminated these various situations that "create" a "list" -- scope,
multiple-object, various disambiguations -- as well as the (standard?)
way to add, remove, modify, and display each.
As is, there's "After deciding.." rules for scope, "Should" rules for
disambig, "deciding whether all includes" (not "AFTER deciding.."),
etc.. There's no consistancy in naming. Or in the operations
allowed: scope is primarily concerned with adding, disambig primarily
concerned with removing and ranking, etc.. It's hard to see how or
whether a given op is allowed on a given list, hard to remember what
can do what, hard to remember how to phrase the appropriate rule
header, and hard to remember what the individual To phrase is to
effect the change.
A modest [partial] suggestion: the Inform way of doing things here
seems to be, make the list then allow the author to fiddle with it.
So the rules for fiddling with any of these lists seems like it should
be an "after <something>" rule. Just as "deciding the scope for" is
the name for creating the in-scope list, and "after deciding the scope
for" is the rule that modifies the list, perhaps "disambiguating" (or
whatever) would be the name for creating the disambig list, and "after
disambiguating" the rules that modify that list, etc.

I wanted
to remove all of the grammar lines using the "[things]" token; this
required having to completely remove a number of commands and re-
introduce all of the grammar lines which didn't use "[things]".

A bit more ambitious solution to that specific problem would be to be
able to declare actions as being able to accept multiple nouns (i.e.,
move this from the grammar to the actions themselves). This would also
give more flexibility to allowing "[things]" to be qualified with
properties (as mentioned elsewhere in the proposal), but I suspect it
would be tricky to make this work nicely (particularly to fit it into
the underlying I6 grammar framework).