Not that it isn't easy to make a candied Lisp dialect with "friendly" syntax more appealing to non-Lisp programmers, but anyone who actually learns a Lisp quickly realizes that it just gets in the way...
If I were to personally try creating an "ideal language" to match my tongue-in-cheek plea, I'd probably start with a terse Lisp-like syntax and a HM-like type system and go from there.
The "meta" in Metaprogramming means that the program is able to manipulate itself (recursively) at runtime. I believe it's theoretically impossible to combine that with AOT type checking and Haskell without its type system would not be Haskell at all.
 Of course you could argue that the sort of thing C++ does with templates is metaprogramming as well, only at compile time. In that case I suggest that we need another term for that because it's totally unlikle what Lisp is so good at.
To put it another way: metaprogramming might have effects at runtime, but not the kind of effects that change depending on what the runtime does. Metaprogramming should be deterministic for your program to be considered to be "in production."
(edit: afaik it doesn't allow the full "recursive manipulation" you describe, but it does let you generate code with code)
Maybe it's not "native" and I have to run system level calls to force compiles and execution of created code.
Almost all programs do metaprogramming (interpreted code, scala on the jvm, etc).
What's the differentiatior for Lisps Metaprogramming (self contained languange structures?).
I'm pretty interested in simplification of programmer interfaces on iteratively more functional (but perhaps more complex) underbellies. I will certainly investigate.
But yes, C++ templates as well as Lisp macros are compile time metaprogramming. All languages that have eval and/or allow function/method bindings to be replaced at runtime allow runtime metaprogramming.
Since static typing guarantees certain invariants it cannot be compatible with a program that violates those invariants at runtime. You could still decide to consider it metaprogramming when the program manipulates itself only within the limits of those guarantees, but when you look at what real world runtime metaprogramming is being used for (for instance in Rails) you will realise that these things (e.g method_missing) would not be possible within the limits of a statically typed language.
 Lisp makes both compile time and runtime metaprogramming exceptionally easy due to its homoiconic nature.
For instance, in order to check that a particular function call conforms to the function signature, the function signature must at least exist. Type checking a call to a function for which not even the signature exists anwhere within the system is impossible.
And yes, the fact that I was essentially asking for a language with both static typing and runtime self-modification was the reason for the tongue-in-cheek "is that so much to ask". Might as well ask for a program that can compile any legal perl program .
That said, I suspect there's a lot that could be done to allow certain subsets of metaprogramming techniques in a static-typed language; some sort of crazy meta-type system that lets the compiler prove that something will only produce code with a particular polymorphic type, maybe? I don't know.
 EDIT: My bad, it's actually parsing perl that's impossible, cf. http://www.perlmonks.org/?node_id=663393
Also, you can generate code (at runtime) which is type-safe, compile the code, etc. Everything you ask for is possible in Haskell, however, it is definitely more complicated than in Lisp.
Static type checking proves that certain invariants hold at runtime and hence that certain defects are not possible. If a program can manipulate itself at runtime in arbitrary ways (not just reflect on itself in a read-only fashion), those proofs become invalid.
Whoa. That doesn't match my experience at all. I'd say it's simple and practically effortless (compared to what you'd have to do elsewhere). It would be surprising if it weren't, given that the whole language is organized around code=data.
If someone built an AMQP library for haskell, we'd probably be 90% of the way there.
See http://www.haskell.org/pipermail/xmonad/2008-November/006723... (if you don't like context, scroll down to 'I had to admit failure').
More practically, Haskell is going to ask you implicitly why you want a heterogenous list of functions. In all likelihood they're going to have a common interface at some point and you abstract around that so that the list is still "homogenous" (which is harder, but still pretty easy).