Let's see...

• 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.)
  
  

It is certainly true that some of the things on my wish list are things Lisp has long been famous for having. Unfortunately, I'm sorry to say, I would really like them in a language that isn't syntactically Lisplike!

I'm not so wedded to the C/C++ style of syntax as to tolerate no divergence from even the bad parts (e.g. C's declarator syntax would probably be the first thing to go if I ever did sit down at the drawing board for serious), but I do think that one or two basic amenities such as an infix expression grammar are not things I'm prepared to do without in the language I use all the time for everything. I tolerate Lispy syntax in my .emacs because I don't spend my whole life writing .emacs; I'd lose patience if I did.

Hm. Come to think of it, maybe "deciding on a subset of lisp and a consistent easy-to-use syntax for it" is what language design should be :)