flush-symbols
    Writeup by: Ram
    Status: written up.

infix expressions are confusing
meaningful names for infix operators
naming conventions for symbols
    Writeup by: rgs
    Status: written up

equality notations
    Writeup by: rgs
    Status: written up

consistent-character-escape-mechanism
    Writeup by: Chiles
    Status: written up

operators-like-c++
binary precedence is largely undefined
    Writeup by: rgs
    Status: Currently rolled into ``meaningful names for infix operators''
	    Maybe should be split out, since it could be adopted or rejected
	    independently.


Harlequin issues that aren't obsolete or already resolved:

symbol/infix-operator-character-sets
    Addressed by CMU:
	infix expressions are confusing
	meaningful names for infix operators
	naming conventions for symbols

equality-notations
    Addressed by CMU:
	equality notations

abbreviations-for-complex-operations
    Disagree on all points:
     -- composition of . and [ is already allowed.
     -- Sacrificing a terse ELEMENT to get multi-d array reference is not
        worthwhile in a language that is not primarily intended for numeric
        computation.  We explored many ideas to allow both, but they were all
        ugly.
     -- Having one namespace for "slots" and functions is a feature, not a bug.

quotation-syntax-and-semantics
 -- We think that "backquote-like" semantics are unnecessary, and would in any
    case require substantial language design effort to hammer it out.
 -- We agree that #`foo` is horrible, but have a different solution, see:
	flush-symbols

comment-to-end-of-line
    We support changing to // and /* ... */, with the proviso that /* comments
    should nest.

parallel-vs-sequential-binding
    Support Harlequin on allowing:
	let a = b, b = a;

    Do not support:
	let values(a, b) = foo();

lambda-list-keywords
    Support Harlequin on changing to key:, next:, etc.