> But what is the purpose of this SRFI? If the purpose is to be able to
> eval untrusted code in a sandbox, then it is just dangerous to offer an
> implementation that is, most likely, not safe on most Schemes.

Possibly of interest, the new work-in-progess SICL implementation of
Common Lisp is designed to support multiple global environments. From
the FAQ (https://github.com/robert-strandh/SICL/blob/master/FAQ.text):

==================================================
First-class global environments

Question:
What are first-class global environments?

Answer:
First class global environments represent a feature whereby the system
may contain several global environments, allowing the programmer to
switch between them, for various reasons.

Question:
Why can't first-class global environments be added to an existing
Common Lisp system?

Answer:
Most existing systems access global functions using an indirection
through the symbol naming them.  This technique makes it impossible to
have different definitions of a function with a particular name in
different environments.  In SICL the "function slot" is detached from
the symbol and attached to the global environment instead.

Question:
Sandboxing is notoriously difficult in existing Common Lisp systems.
Will it be easier in SICL?

Answer:
Yes, first-class global environments allow the creation of restricted
environments so that one may, for example, disallow the evaluation of
arbitrary forms.

Question:
Will SICL be safer than existing Common Lisp systems?

Answer:
Yes, with existing systems, the entire code is always available.
Nothing prevents an external system from modifying the compiler to
install a virus, or from forking a process in the name of the
unsuspecting user.  With first-class global environments, it is
possible to isolate sensitive code so that some additional action
(password maybe) on the part of the programmer is required in order to
access or modify it.
==================================================