This is one of the most complex extensions to the fundamental core of
Scheme I've ever seen.  Although I won't claim that it has no
historical precedent, I have to wonder whether the bulk of it couldn't
be greatly simplified.  I had written up a draft a while ago for a
basic optional positional parameter SRFI, but its bulk was in
explaining its rationale in comparison to other mechanisms (SRFI 16's
CASE-LAMBDA and Olin Shivers' LET-OPTIONALS) and in elaborating on
implementation strategies.  For those curious, it's at

  <http://mumble.net/~campbell/proposals/optional.text>.

I am personally generally opposed to named parameters intermixed with
positional ones.  Most of the examples of code in the SRFI 89 document
are either very contrived or can be expressed without using named
parameters, in some cases much more simply, either by instead using an
alist or by changing the idiom of parameter passing; macros for
picking apart such alists of options are helpful.

For example, R3RS had an elaborate number formatting library based on
list-structured formatting specifiers, rather than named parameters
to NUMBER->STRING.  For XML output, I think simply having a list of
attributes makes *much* more sense than manually specifying every
possible attribute at the definition site:

  (define (make-html-styler tag)
    (lambda (attributes . content)
      (element tag content
               (map (lambda (a) (attribute (car a) (cadr a)))
                    attributes))));

although this doesn't provide static guarantees of the allowed
attributes, one can always insert checks later on (e.g., with another
parameter to MAKE-HTML-STYLER).

As for n-ary procedures with named parameters, I always find them very
confusing.  I don't think the port parameter to I/O procedures should
be optional in the first place, and rather than the PRINT procedure
described in this SRFI for generating complex output I prefer a
higher-level and more structured library of output combinators,

  <http://mumble.net/~campbell/scheme/output.scm>,

in which the various OUTPUT-... procedures return procedures that take
a single port parameter and write the output to it.  I've built a
structured XML output library based on this idiom, in fact, which is
very simple but equally general.

I'd like to see some compelling examples that demand named parameters
and for which alists of options would not suffice, perhaps for
performance reasons or otherwise.  In my experience I can't recall
ever having found any good ones, really; do you have any particularly
compelling examples where you found named parameters with this
mechanism much more appropriate than any other mechanism, or than
separate procedures to do different jobs?