Suppose an experimental D evaluator accepts eval("rate + 1", env), with rate bound to 3 in the supplied environment. Under the proposed rules, that expression would mean 4 in either compile-time or runtime mode. Changing a mutable host global named rate to 9 would have no effect on that input.
I would make the environment explicit even if a global lookup makes the first example shorter. D evaluates eligible functions where compile-time values are required, and CTFE expressions cannot reference mutable globals or statics. That restriction is a useful pressure test. It does not make every function CTFE-capable or turn CTFE into an arbitrary security sandbox.
The tradeoff is that the host must assemble and pass the bindings it wants the evaluator to see. In return, the proposed evaluator can give the same supplied expression and environment the same meaning in both modes. I would reject an implicit fallback to a host global when rate is missing. Any runtime recovery interface should be documented separately, including whether a replacement becomes part of the evaluation input.
