• Multi-paradigm is good, Do Everything My One True Way is bad. Some things are OO-shaped, some functional-shaped, some plain procedural, and you want to be able to switch back and forth within different parts of the same program without undue faff.
• Compile to nice fast native code, or at the very least, don't design any language so that you can't sensibly do that. Requiring users to wait for Moore's Law is a mug's game.
• Complete and correct bindings to all OS APIs. This is a major thing that keeps me using C and occasionally C++ in spite of their many flaws: whenever you use a different language, you sooner or later end up having to do some OS interaction that that language's abstraction didn't bother to include. But it's not really a language feature as such; I think what I really want is for all OS maintainers to publish cross-language specs for their APIs so that every language can auto-process them into its own appropriate form.
• Define the language semantics better than C/C++. Undefined behaviour can bite you in so many different ways, and you have to know all the gotchas to reliably avoid it. Each language feature should be safely usable without having to be an expert in the rest of the language first.
• Check as much as possible at compile time; in Python it's really annoying to find a code path your tests didn't encounter crashing in the field due to a typo or type-o that static type checking would have picked up instantly.
• Make it possible to extend the language in a metaprogramming-type way, but try to do better than C++ at making the simple things simple, and try to avoid the need for puzzle games (which C++ is no better at doing than C – the CRTP is a good example).
• Managed languages (GC, bounds checking etc) versus non-managed (C/C++ with feet firmly in the line of fire at all times) I'm not sure about; sometimes I think what I'd really like is a hybrid (e.g. GC with an optional explicit free operation which causes an allocated thing to become instantly invalid, so that refs from it become GCable in turn and refs to it throw a StalePointerException, and also I want a feature to let me conveniently treat a big byte array as an unmanaged sandbox), and other times what I think I'd really like is a means of writing unmanaged code which includes a static compile-time proof that you don't overrun any array etc. Probably neither is actually feasible.
• I'm vaguely intrigued by aspect-oriented programming, in that it seems to be a reaction to a thing that's annoyed me a lot, but I've never actually tried it so who knows if it would work well in practice. I think ideally I'd just want a metaprogramming facility strong enough to let me do it myself if I happened to feel like it in a particular program.
• Extending 'define the semantics clearly' above, a slightly silly idea that I can't quite convince myself is actually wrong would be to specify that all intermediate values in integer arithmetic expressions have the semantics of true mathematical integers, to the extent that the runtime will link in GMP or equivalent if it really has to (which I wanted available anyway, since arbitrary-precision integers are a really nice facility to have available and the best thing about Python is that it provides them as a native type). Narrowing should occur only as a result of an assignment or explicit cast. If you need speed, you can request a compiler warning when the expression you've written requires GMP to code-generate, and then manually insert casts to eliminate the need; then you'll be in control of where the casts go and won't be startled by them.
• My biggest blue-sky wish is that I'd like a built-in language feature to construct pieces of code on the fly and JIT them into native code, so you could implement all sorts of user-scripting of things in a way that was actually reasonably efficient, and also increase the use of the approach "first laboriously work out exactly what you want to do, and then do it in a loop a zillion times really fast".
• AND A PONY. There, see what I mean?

    array-of-double coefficients; // coefficients of a polynomial
    array-of-double input, output; // desired evaluations of the polynomial

    // Construct a function to evaluate this polynomial without loop overhead
    jit_function newfunc = new jit_function [ double x -> double ];
    newfunc.mainblock.declare { double ret = 0; }
    for (i = coefficients.length; i-- > 0 ;)
        newfunc.mainblock.append { ret = ret * x + @{coefficients[i]}; }
    newfunc.mainblock.append { return ret; }
    function [ double -> double ] realfunc = newfunc.compile();

    // Now run that function over all our inputs
    for (i = 0; i < input.length; i++)
        output[i] = realfunc(input[i]);

So an important aspect of this is that parsing and semantic analysis are still done at compile time – the code snippets we're adding to newfunc are not quoted strings, they're their own special kind of entity which the compile-time parser breaks down at the same time as the rest of the code. We want to keep runtime support as small as we can, so we want to embed a code generator at most, not a front end. The idea is that we could figure out statically at compile time the right sequence of calls to an API such as libjit, and indeed that might be a perfectly sensible way for a particular compiler to implement this feature. The smallest possible runtime for highly constrained systems would do no code generation at all – you'd just accumulate a simple bytecode and then execute it – but any performance-oriented implementation would want to do better than that.

Importantly, the function we're constructing gets its own variable scope (ret in the above snippet is scoped to only exist inside newfunc and wouldn't clash with another ret in the outer function), but it's easy to import values from the namespace in which a piece of code is constructed (as I did above with the @ syntax to import coefficients[i]). It should be just as easy to import by reference, so that you end up with a runnable function which changes the outer program's mutable state.

Example uses for this sort of facility include the above (JIT-optimising a computation that we know we're about to do a zillion times), and also evaluation of user-provided code. My vision is that any program which embeds an expression grammar for users to specify what they want done (e.g. gnuplot, or convert -fx) should find that actually the easiest way to implement that grammar is to parse and semantically analyse it, then code-gen by means of calls to the above language feature, and end up with a runnable function that does exactly and only what the user asked for, fast, without the overhead of bytecode evaluation or traversing an AST.

var poly = function(x) { return 0; }
for (i = ncoeffs; i-- > 0 ;) {
    builder = function(p, coeff) {
        return function(x) { return x*p(x)+coeff; };
    };
    poly = builder(poly, coeffs[i]);
}

• Multi-paradigm: oh, yes. We got that.
  
  
• Fast compilers: check. More or less. Common Lisp is dynamically typed, but with optional type annotations. Good compilers can do extensive type inference. By default, Lisp is fairly safe (array bounds are checked, for example), but this can be turned off locally. Common Lisp was always intended to be compiled, and designed by people who'd already made Lisp implementations competitive with the Fortran compilers of the day.
  
  
• OS bindings: hmm. Every decent implementation has an FFI. The last time I looked, the CFFI-POSIX project wasn't going anywhere, though.
  
  
• Semantics: yep. Pretty good ANSI standard; a draft of it is available online as an excellently hyperlinked document -- the `HyperSpec' -- which, to the tiny extent that it differs from the official standard, probably reflects real life better. Common Lisp nails down a left-to-right order of evaluation, which eliminates a lot of C annoyance; aliasing just works correctly; and while runtime type-checking isn't mandated, all implementations I know of will do it unless you wind the `safety' knob down.
  
  
• Compile-time checking: hmm. A decent implementation will surprise you with how much it checks, even in the absence of explicit annotations. Unlike Python, Lisp implementations will want you to declare variables explicitly or they'll give you lots of warnings. SBCL's compiler diagnostics are less than excellent. The usual clue is that it emits a warning explaining how it elided the entire body of your function, and then you notice that it proved that you'd passed an integer to `cdr' somewhere near the beginning. If you like writing type declarations then you can do that and get better diagnostics.
  
  
• Metaprogramming: Lisp's most distinctive feature is that it's its own metalanguage.
  
  
• Explicit free: no, sorry. The FFI will let you allocate and free stuff manually, but it's a separate world filled with danger.
  
  
• Slabs of bytes: a standard part of the FFI. Don't expect this to be enjoyable, though.
  
  
• AOP: you can probably make one out of macros. Maybe you'll need a code walker.
  
  
• Integer arithmetic: Lisp integers always have the semantics of true mathematical integers. Lisp systems typically have lots of different integer representations (heap-allocated bignums; immediate fixnums which have type-tag bits and live in the descriptor space; and various sizes of unboxed integer used for intermediate results, and as array or structure elements) and use whichever is appropriate in any given case (so `narrowing' occurs automatically, but only when it's safe). A good compiler, e.g., SBCL, will do hairy interval arithmetic in its type system in order to work out which arithmetic operations might overflow. If you wind up SBCL's `speed' knob you get notes about where the compiler couldn't prove that overflow was impossible. SBCL also has some nonportable features for declaring variables which should have wrap-on-overflow semantics instead.
  
  
• Runtime compiler: got that too. It compiles Lisp code to native machine code. And it's used to program-generated code, because of all the macro expansions.
  
  
• (asdf:operate 'asdf:load-op "CL-PONY"). (Not really.)