Context of &OPTIONAL and &AUX calculations

[Jon L White <JONL at MIT-MC>]

    Date: 1 August 1981 12:14-EDT
    From: George J. Carrette <GJC at MIT-MC>
    Subject: I hate to tell you but...
    ...
    (DEFUN G (Y) (SETQ X (+ X Y)))
    (DEFUN H (&OPTIONAL (X (G X))) X)
    ...
    I'll admit that the example is contrived, however, note well
    that it used to work, when the code generated was a simple
    use of LET* .  .  .
At one time, the LISPM did the following for &OPTIONAL and &AUX calculations:
  1) Create a bind frame with all the relevant variables in it, being bound
     to their previous values, if any.
  2) Sequentially set each &OPTIONAL variable to either the input arg [which
     might mean no code output], or set it to the default calculation.
     Then sequentially set each &AUX variable to its calculation.
This order has the happy effect that &OPTIONAL and &AUX calculations don't
disturb any special variable bindings in the outer contour, where there
is an ** apparent LAMBDA binding ** of that special variable in the function.

I still feel that that original scenario is the better one, since it
is more in accord with the notion that the implicit LAMBDA binding of
the argument variables will "shield" the outer contour.

Could this situation possibly have any practical significance? or is
it only going to occur in, as you say, "contrived" circumstances?