Syntax loose ends: inline error names, explicit scoping for namedexpressions (sheet-local/global)

["David A. Wheeler" <dwheeler@dwheeler.com>]

In the syntax section there are a few TODOs; most are done
and need to be turned into Notes/Rationales.

But there are two TODOs that still need addressing; they are both
edge cases, rarely used:

1. Inline error names.  You should almost NEVER have an
named inline error in a function (though calculation may PRODUCE one).
But we need the functionality.  There's a proposal on the table to
drop the "/" character in exchanged error names. That might simplify parsing
(otherwise, some folks have to make an effort to prevent it from being
considered division).  If we do that, we could go further and just
make errors match this pattern:
   '#' Identifier
That _might_ simplify all sorts of things. Then the "should" error names
where they have equal meaning would look like this:
Old             New
#DIV/0       #DIV0
#NAME?      #NAME
#N/A          #NA
#NULL!       #NULL
#NUM!        #NUM
#REF!         #REF
#VALUE!     #VALUE

What does everyone think? Anyone have a preference?
(If so, please tell us why!).

2. Sheet-specific vs. global named expressions.  Some applications have
"sheet-specific" named expressions, that aren't the same as a named expression
globally applicable (Excel and Gnumeric at least do this).
Should we have a syntax to explicitly reference one or the other?
This is particularly an issue when referencing external sheets.
I'd particularly like to hear from the app implementors who implement
this separation (I'm not sure if OpenDocument supports this; if not, we'll
need to address this scoping issue there too).

--- David A. Wheeler