The features can and likely will be present in
some implementations, namely some interpreters
(those implementations that try to  make EVAL
low-latency and high-as-practical throughput).

Therefore, the features will be useful for writing
standard implementations of things like syntax-case
or PLT modules.   For example, the reference
implementation in a SRFI could reasonably use these
features.   People will be able to play around with
the features in interpreters that support them and
can decide, in their own implementations, to provide
the SRFIs but not the very dynamic features themselves.

An interesting question is whether there can be
implementations that contain both an interpreter
and a compiler such that if code does make "crazy"
use of fexprs the compiler just gives up (and the
interpreter takes over) but if code uses only,
say, syntax-case macros and PLT modules an optimization
pass eliminates all fexprs and first-class environments
from that code.

Now, an implementation has at least three choices:

         Provide FEXPRs/        Provide
         environments?          syntax-case?

1)            no                    no
2)            no                    yes
3)            yes                   yes

Note that there is no "yes/no" choice because of the
reference implementation of the SRFI:  if you provide
FEXPRs/environments then you get syntax-case "for free".

Most existing implementations of R5 immediately
qualify as conforming in sense (2): no fexprs and
environments but, yes, they have syntax-case.

There is another way to look at the options
implementations will have.   Consider implementations
in classes (2) and (3), above -- those that provide
syntax-case.    They have a choice:  they can
implement syntax-case directly, as a special case
in the compiler or interpreter, or they can use the
reference implementation.    For exaple, a compiler
might not support "fexprs and environments in general"
but might tolerate them in an early "pass" if they
can be more-or-less eliminated from the code by
constant folding and other forms of partial evaluation.

It seems to me that Scheme's history is unduly
influenced by a period of time when it seemed very,
very important to benchmark serious Scheme compilers
against languages like C.   So, there
was a lot of sentiment to make sure that the core,
standardized language was 100% compilable (c.f., the
resistance to EVAL).

I think that that emphasis on compilation is, more
than anything, what has all but killed Scheme's
real-world successes.   It forces every author of a
Scheme program to solve constraints imposed by a
compiler writer, and for very little return:

If you need a low-level language characterized by
tightly compiled code, C and C++ are still the best
choices by far.   If you need a high-level language
with tight-as-practical compilation, Java wins over
Scheme and now Haskell is moving up.

And, tragically: if you want to just hack in a high-level
language, innovating freely, not terribly concerned
about performance, and often adding features by *in
effect* building domain specific languages (one of
Scheme's alleged strengths) -- evidence on the ground
is that you're best off using Lua, Ruby, Perl, PHP,
Python, or any of similar ilk.   Those languages
are, each every one of them, filled with horrible warts
compared to Scheme but they have this strength:
millions of programmers can well-enough grok how they
work, and they work flexibly enough, to experiment with
"gross" hacks that get a job done (e.g., ActiveRecord in
Ruby, objects in Lua, etc.)   It's as if Schemers look
at what's going on in those languages, correctly decide
"that's the wrong way to do it," but then mysteriously
and sadly conclude "there must be no *right* way to do
it."

Scheme's historic strength is to provide a very wide
range of functionality out of just a few, parsimoniously
chosen features.

I see no parsimony in things like module systems and
macro systems, especially when they are so complex,
so limited, so arbitrarilly chosen from among the options,
and so overlapping in what underlying (but unsurfaced)
concepts they rely on (such as syntactic environments).

Fexprs and environments surface the underlying concepts
in a practical way, directly, allowing not only the presently
considered macro and module systems but much more beyond.
Fexprs and environments, in an interpreted setting, put
Scheme (and its advantages) in the game against already-
flexible interpreted languages like Lua, Ruby, et al.

I think Scheme is going to go in the more dynamic direction
on its own.   It's just too simple and correct an idea.
In some sense, the only question is whether or not the
revised report series will remain a legitimate source of
authority on Scheme.