ksh93's manual-page states:

----------------------------8< cut here >8------------------------------
       - exec [ -c ] [ -a name ] [ arg ... ]
              If  arg is given, the command specified by the arguments is exe-
              cuted in place of this shell without  creating  a  new  process.
              The -c option causes the environment to be cleared before apply-
              ing variable assignments associated with  the  exec  invocation.
              The  -a  option causes name rather than the first arg, to become
              argv[0] for the new process.  Input/output arguments may  appear
              and affect the current process.  If arg is not given, the effect
              of this command is to modify file descriptors as  prescribed  by
              the  input/output  redirection  list.   In  this  case, any file
              descriptor numbers greater than 2  that  are  opened  with  this
              mechanism are closed when invoking another program.
----------------------------8< cut here >8------------------------------

Bash implements this, and the -l option too.

I suspect that a lot of the time, these exec options will be used for
remote commands, as a recent poster encountered, and being incompatible
with bash will just cause growing pain for users in this special case.
(I'm not setting out to dup bash).

I've started implementing the compatibility; I've documented all three,
implemented -l and -a.  I'd like feedback before continuing:

 (1) is this worth doing at all, or should I stop?
 (2) to implement -c, is it best to change the interface to execute()?
     Are there any compability issues with modules if I do that?  I was
     thinking of changing the second parameter from "dash" to "flags"
     and using the same BINF_ option-space, but with a BINF_CLEARENV
     flag added; just clear the env _after_ checking for ARGV0 and it
     looks valid to me.
 (3) am I going about all this the wrong way?

Thanks,
-Phil