Here are some initial comments.  Earlier, I sent most of these to Joo
ChurlSoo, but I wanted to resend them to the discussion list.

Immutability typically means the meaning of a variable (or in the case,
the field of a record object) cannot be changed (mutated) once
constructed, but you show examples where precisely this happens:

;; The `color' and `coordinate' are immutable automatic fields.
(define-lambda-object (cpoint ppoint)
   (x) y
   (,color 'blue)
   (,coordinate (lambda (i j) (set! x (+ i x)) (set! y (+ j y)))))

Notice y is immutable, yet set! by the coordinate method.

Joo ChurlSoo writes in response:
> I think personally it would be better for a method that cannot be
> accessed by others to have such a function irrespective of
> immutability.

I'm not sure I know what that sentence means.  If the value of a field
can be mutated after construction, it is not immutable.  Either the
language should change (don't describe this as mutable vs. immutable) or
the behavior should change (don't allow immutable fields to be mutated).

I am not able to reconcile the text about accessors and mutators being
non-generative with the text saying "Each time define-lambda-object
expression is evaluated, a new group is created with distinct <group>,
<constructor>, and <predicate> procedures."

Joo ChurlSoo writes in response:
> I mean the accessor and mutator are nongenerative, that is,
> even though the same define-lambda-object expression is evaluated twice,
> new accessor and mutator are not generated.

You should include examples that demonstrate the generative or
non-generative features of this proposal.  (I am still confused about
how this issue).

Where are define-lambda-object forms allowed to appear in programs?  In
any context which allows definitions?  Or any expression context?  The
name suggests only in definition context, but you also frequently refer
to define-lambda-object forms as "expressions."

Joo ChurlSoo writes in response:
> The lambda-object-defining form `DEFINE-LAMBDA-OBJECT' is a definition
> and can appear anywhere any other <definition can appear.

I suggest the above be added to the document.  I also suggest not
referring to these definition forms as expressions.

I strongly dislike the use of parenthesis and the keyword UNQUOTE to
disambiguate the field specs in this proposal.  It makes it very
difficult to look at a definition and infer what it means.  I would
suggest using informative keywords like MUTABLE, IMMUTABLE, REQUIRED,
AUTOMATIC, etc.

The use of define-macro in the reference implementation detracts from
the portability and will likely limit the adoption of this SRFI.

David