> That implementations may extend an srfi is, imo, implied anyways, no?

As far as I understand, extension points to SRFIs are either
it-is-an-error situations, or explicit statements to about extensibility.

So adding optional arguments to a procedure is OK, since passing the
incorrect number of arguments to a procedure is an error situation, and
anything goes in an error situation.

Adding new identifiers to a library exported by an SRFI would be a
violation of the spec of the SRFI, because those newly imported
identifiers could conflict with other imported identifiers. (For
example, if I made my SRFI 263 implementation export some identifier
named `cons`).

(I hope my understanding of the object system is correct in this
example:) For example, imagine if my implementation extended the
`mirror` object with a new default method `do-foo`. Then any invocation
of `do-foo` on a mirror object would use that default method. If I were
to add a `do-foo` method explicitly to a parent mirror object, and then
make a mirror object of a child class, then `do-foo` on the child mirror
object would either refer to the child object's `do-foo` or the parent
mirror object's `do-foo`, depending on if I use my implementation or
others's implementation.

So allowing extensibility everywhere while still being called "SRFI ###"
can be an issue. It could still be allowed but is a design tradeoff and
should be stated explicitly.

It's less of an issue for the root object, because presumably if the
method doesn't exist it just raises an error. So adding
implementation-defined methods to the root object is different than
adding implementation-defined methods to other derived classes.

 > The lists themselves that are returned are shallow copies.

Thank you for the clarification. One final one for this subject: do the
lists of three elements of immediate-slot-list and full-slot-list or are
they generated on each call?

Since the lists are the same length and contain the same objects, it
might be better to make them record types. Then I could access the
information with slot-getter, slot-setter, slot-type, etc. Or they could
be objects in the sense of this object system and have 'getter, 'setter,
and 'type messages.

-- Peter McGoron