The newcomer (whether troll or real) could easily walk away from this
saying:
  "Hmm...   Special variables.  I wonder what those are?"

A quick look at the HyperSpec certainly does _not_ cause the
implications of them to leap out at one; the quick browse raises a lot
more questions than it answers:

 - Why did you say "special variable," when all the glossary indicates
   is "see dynamic variable"?

 - Then there's these other terms, "dynamic extent," "indefinite
   extent," "dynamic scope," and "dynamic environment."  They all seem
   somewhat relevant, but how does it go together?

It definitely isn't a "pithy" explanation.

The section in CLTL2 on "Scope and Extent" explains it a little more
clearly, I think, but it doesn't get to the point of explaining why it
would be considered _important_.

A reasonably "pithy" example is shown here:
  <http://www.n-a-n-o.com/lisp/cmucl-tutorials/LISP-tutorial-12.html>

It doesn't say anything that would cause Special Variable to "leap to
mind as the obvious first choice."

Note that I'm not disagreeing with the notion that SV's are useful or
important; I _would_ disagree with the notion that this is either
obvious, or even a represents a notion readily accessible to a novice.

I don't think _any_ of the items you list are "obviously obvious;" I
just did a quick review of the set of introductory documents on CL,
and few give much, if any treatment of them.

That could mean (at least :-)) two things:

1.  Perhaps you're wrong.

    I don't think you're particularly wrong.  There could be quibbling
    over "who's on first," but the features you describe do appear
    like good candidates for "_much_ higher level of abstraction."

2.  The literature is doing a bad job of communicating these sorts of
features.

This seems to me to be a _whole_ lot more likely.

There are two books on CLOS (one of which I have seen) which describe
its merits.

"On Lisp" sells hard the power of macros.

Various references do describe the importance of closures.

But the "You really need to know and understand and use special
variables, the type hierarchy, and custom readers" parts are _not_
"evangelized" in the literature in similar manner to [say] CLOS.

Note that I am _not_ being critical about either CLTL2 or CLHS on
this; they do not have, in their proper scope of intent, the mission
of explaining: "Here are techniques that you should use!"

  Then you go write them.  In my experience, examples illustrating an
  unknown concept usually mislead people.  Besides, writing examples that
  actually work to illustrate _concepts_ takes a lot of time and effort.
  May I tell you that publication here is not exactly _rewarded_ when you
  only complain about people not doing enough to satisfy you?  Why not just
  write and publish the stuff you missed yourself if it would be so nice?

| I think the world could use an "essay" or "book" that describes 7
| different applications of readtables, for instance, sort of paralleling
| Keene's book on CLOS.

  Again, feel free to write it yourself.  It is quite enjoyable until you
  get complaints from people who _demand_ more without any encouragement.

  This is true, but extending the concept of special binding to threads is
  not a conceptual hurdle, it is more of an implementational hurdle.

| In my opinion an optimal implementation of per-thread special variable
| bindings does not require any re-binding.

  I was unspecific.  The design I had mind was threads managed by a single,
  monolithic process, but I did cover the case of separate processes, as
  well, those needing IPC and shared memory.  I.e., the process scheduler
  in the Common Lisp system, not the kernel, would have to do a context
  switch that would include saving and restoring the binding stack of the
  new context.  This is one of the drawbacks of having your own scheduler,
  but there are also serious drawbacks to using operating system threads
  and processes, especially when using shared memory for all the global
  _objects_, and that includes code.

| And if all those threads are active at once, no problem.  No context
| switching need occur.

  Well, context switching between threads at the operating system level is
  different from context switching between threads when privately managed.

| I can't see a reason for a thread to re-bind it, and then have all other
| threads see the binding.

  That was clearly not what I wanted to say, either.

| I think you would have multiple threads trying to undo each others
| bindings, possibly.

  Only if you assume a globally shared memory and operating system threads.
  I find it fascinating that you only consider those kinds of threads and
  not the well-known technique of managing multiprocessing privately.

My apologies for straying just a teensy bit, but the truth about
COM/DCOM is so poorly understood by non-Windows people that it
bears pointing out.

In both RPC and CORBA IDL's, one can write:

struct Point {
     int x;
     int y;

Various service packs and releases of language runtimes were
supposed to make all of this go away at some point. As a company
we escaped the whole COM/DCOM/COM+ debacle and discovered that
underneath all that cruft is a fairly reliable and capable OS.