esl> I don't think the problem with internal record definitions is in
    esl> implementation complexity - it's in generativity. If you define
    esl> a new record type inside a procedure, it is natural to expect
    esl> the same record type each time you enter the procedure; otherwise
    esl> the objects you created before won't be recognized by record
    esl> type predicate:

    esl> ;; sample enumeration protocol for nonempty sequences:
    esl> (define (enumerate-stuff state) ;=> obj, {next-state or #f}
    esl>     (define-record-type my-enum-state ...)
    esl>     (if (eq? state #f)
    esl>         ;; start enumeration
    esl>         (values obj1 (make-my-enum-state ...))
    esl>         ;; continue enumeration
    esl>         (let ((next-state (if (has-next? state)
    esl>                               (next-state state)
    esl>                               #f)))
    esl>             (values (state-obj state) next-state))))

Actually, I hesitated to make the comment about internal defines until
I realzed that the datatypes were already generative.  I think
generativity is one of those things well-meaining people simply
disagree on.  For me, I _want_ datatypes internal to procedures to be
generative on procedure application.  It just seems natural.  If you
rewrite enumerate-stuff without the MIT-define, it seems clear to me
that the define-record-type belongs outside of the lambda and inside
of the define:

;; sample enumeration protocol for nonempty sequences:
(define enumerate-stuff
  (let ()
    (define-record-type my-enum-state ...)
    (lambda (state) ;=> obj, {next-state or #f}
      (if (eq? state #f)
          ;; start enumeration
          (values obj1 (make-my-enum-state ...))
          ;; continue enumeration
          (let ((next-state (if (has-next? state) (next-state state) #f)))
              (values (state-obj state) next-state))))))

-erik