> OK, it's implicit enough in the text and examples I don't have to say
> anything extra about this.  Thanks!

Yep, no need to say anything special.

>> What does `foreign-status-plist` do, return the whole plist?
>
> Yes.  Except it may generate a new plist because (2nd item below):

Good.

>> Does enumerating the properties need to be in the API?
>
> My theory is no, because plists are so simple, although it would be
> nice to have a plist SRFI, even as a placeholder, to direct people to
> for simple utilities like that.  The foreign-status-properties you
> suggest below would just duplicate one of its procedures.

It doesn't just duplicate a generic plist procedure, it maintains
encapsulation.

Our keys are dumb objects - just symbols. Values may be smart
(transparent lambdas), as may the container type (can use something else
instead of plist). A procedure that enumerates just the dumb parts more
easily handles the abstraction as it evolves.

A `foreign-status-plist` will have to fetch values for all keys, even
such keys that are not of interest to the caller. If we add transparent
lambdas, then *all* of them will be called in a non-deterministic order
whenever the user does `foreign-status-plist`.

Forcing the user to explicitly call `foreign-status-ref` as the sole
value accessor makes it explicit to the user when they are resolving a
property value.

>> and we can postpone the decision about transparent lambdas.
>
> Right now transparent lambdas are off the table, and I assume won't be
> put back on it unless and until we nail down localization, and then
> look at it and say, hey, this bit right here should be magical like that.

Please at least consider my points above. It's not good to pin things
down too early.