Tsk tsk, you can't declare special cases that favor your side of the argument this late in the game.

Whilst selecting codepath depending upon the (sub)type of a scalar at runtime is definitely a form of introspection, the fact that it is under compiler/interpreter control, rather than programmer control, makes it a somewhat different animal to the normal

First of all, it happens at runtime and it is introspection, so therefore it is runtime introspection. It may seem that the programmer is not explicitly asking for it to be done (as in the my example above with ref/can), but the programmers choice of language features have caused the interpreter to do runtime introspection just the same. Ignorance of the underlying technique used by the language to accomplish the things you ask for does not make it any less what it is, which is runtime introspection.

Indeed, I would say that run-time dispatching upon the base type (HASH/ARRAY/SCALAR/CODE etc.) of a reference is likewise, something of a 'special case'

Nope, wrong, no special cases allowed, you made a pretty clear statement, lets not muddy it up.

Even that aside, lets take the case of OCaml. Ocaml is a very strongly typed language and the OCaml compiler spends quite a lot of time rigorously analyzing the code to make sure it is well typed and optimizing it as much as possible. Why does it spend all this time? Well because once compilation is finished, OCaml discards pretty much all of the type information. Yes, that means ref ocaml_variable == 'ARRAY' is completely impossible to do.

So (IMO anyway) it is not fair here to add a special case here, because this is just simply not possible in other languages which don't have runtime introspection available. If this were some kind of universal language feature, then maybe, but it is not.

The types of reflection that I'm more intrigued by the need for, are those provided by the use of UNIVERSAL::ISA and UNIVERSAL::can and similar. These seemed to be used to provide for 'generic programming' ala C++-style templating solutions. In simplistic terms, as a substitute for providing essentially copy&paste dedicated methods, or resorting to MI and/or deep inheritance trees.

Yes, these things are far more exciting, however I fail to see how they are any different from the clone example I provided above? Sure if everything is an object, then I can use polymorphism instead of manual type introspection to fake polymorphism, but just as I said above, just because the runtime system is doing it for you and you are not explicitly asking for it doesn't make it any less.

An alternative to introspection for dynamic languages is compile-time code generation.

Well, no, that is not 100% true. Compile-time code generation has it's limits, some things just simply cannot be known at compile time (user input, information from the network, etc), and depending on what you are doing with those things, you can't always generate enough code to handle all those cases. And even if you could, it is likely that runtime introspection would be simpler code and quite possibly more efficient as well. Generating many reams of code to replace a simple bit of introspection seems a silly tradeoff to me.

As I said above, the best of both worlds is the ideal. Some things are better expanded at compile time, while others are better introspected at runtime. Anyone who has spent any time writing code in very strongly typed languages like Ada/Haskell/OCaml/etc. will have encountered inflexibility that has caused them to have to write complex code for the compiler that could be solved simply and elegantly at runtime. And anyone who has spent any time writing code in more dynamic languages like Perl/Python/Ruby know that sometimes you have to write silly and inefficient code to do something that the compiler really aught to be able to figure out on it's own.