(let ((unnamed (lambda (me obj)
                   (if (atom obj)
                       obj
                     (cons (funcall me me (cdr obj))
                           (funcall me me (car obj)))))))
    (funcall unnamed unnamed '(a b c)))

This lets you get to call "the unnamed lambda" as ME within its body.

  (defmacro fakelambda (lambda-list &body body)
    (let ((args (gensym)))
      `(lambda (&rest ,args)
         (labels ((me ,lambda-list ,@body))
           (apply #'me ,args)))))

but then the returned function can't be usefully inspected.  I wonder
if this can be made to work with supplied-p parameters and all that...
ah, now I get it!

  (defmacro fakelambda (lambda-list &body body)
    `(labels ((me ,lambda-list ,@body))
       #'me))

The implementation in most Scheme implementations is the same as how
you'd do it in Lisp, they just don't tell you.

 (defmacro letrec (bindings &body forms)
   `(let ,(mapcar #'car bindings)
      (setq ,@(mapcan #'copy-list bindings))
       ,@forms))

The only difference is that in Common Lisp, because we have two namespaces,
you call a variable's value with funcall instead of like a function.

 (letrec ((fact (lambda (x)
                  (if (zerop x) 1
                      (* x (funcall fact (- x 1)))))))
   (funcall fact 6))
 => 720

Not that you couldn't put some syntactic sugar around that if
you wanted to.  Consider:

 (defmacro fletrec (bindings &body forms)
   (let ((temp (gensym)))
     `(let ,(mapcar #'car bindings)
       (flet ,(mapcar #'(lambda (binding)
                          (let ((name (car binding)))
                            `(,name (&rest ,temp)
                                (declare (dynamic-extent ,temp))
                                (apply ,name ,temp))))
                      bindings)
          (setq ,@(mapcan #'copy-list bindings))
         ,@forms))))

When you write macros in production code, do you make them
strictly check the syntax of arguments and signal errors for
things like (LETREC ((VAR 'VAL EXTRA)))?  Is DESTRUCTURING-BIND
good for that?

But there are about 117 other ways to win, so it's not like you're stuck.

LOOP has an appending collection mechanism.

And (reduce #'append lists) or (apply #'append lists) probably would have
done it.  I just used the first thing that came into my head.
In spite of what you've perhaps been told, NCONC is not evil nor to be
avoided, nor are all cases of COPY-LIST wasteful.
Note that these calls to COPY-LIST are (mostly) not doing extra copying--those
cons cells WILL be copied anyway even if
you use APPEND.  MAPCAN+COPY-LIST just makes the copying explicit...

It's true that it adds a tiny amount of extra work in the rescan, but
really not worth fussing over unless this is the inner loop of some very
long computation.  In the case at hand, it just isn't, and any time spent
trying to fuss over further optimization is time wasted from your life.
Take the same time you would have spent optimizing such things and be home
for dinner just a little earlier, and you'll be happier all around.

Programmers waste too much of their lives optimizing things that do not
matter.  This means they are home late for dinner unnecessarily too often,
and it also means that even when they'd not be going home but would be
staying to work more, they're working more on the wrong things.  Computer
science has bigger problems than making this little piece of code fast.

I am not kidding.

Common Lisp is about doing things in practical ways.  LOOP, for all
its syntactic weirdness, is often the most practical in a number of
circumstnaces.  It really needs to be in your arsenal of things you're
willing to try, or you're crippling yourself.

If you really, really want to spend your whole life nitpicking about small
details and not ever getting on to the problems that are holding mankind
back, no one is stopping you.  But I can't stress strongly enough how little
I think this kind of thing matters and how important it is to learn to tell
the difference between things that do warrant careful scrutiny and things
that do not.

(It's not like I myself never obsess on things that don't matter, mind you.
I'm just hugely conscious of it, and waste a lot of time needlessly obsessing
about that, too...)

APPLY is probably the cheapest in this case if you know the set of
lists will always be short enough for it to work.  (There's a
limitation of how many lists you can use in APPLY because of
CALL-ARGUMENTS-LIMIT, as you note below.)

And, btw, optimization is almost always a per-vendor activity.  Each vendor
does it a different way.  It's good to talk here if a vendor says something
can't be optimized and you disagree and want suggestions.  But the standard
can't and doesn't specify optimizations.

Incidentally, even keyword calling (the :FROM-END T) can introduce extra
time into your calculation, but I recommend you also not worry about that
unless it gets out of hand.  In principle, an implementation can optimize
that out.  In practice, most just focus on the common cases and leave the
others for a rainy day.

-- -- --

To be clear:

 * I think it's good for vendors to care about this kind of speed issue.

 * I think it's ok for users to care about this kind of speed issue
   if it is a known bottleneck in a real application.