That makes sense, and I do wish that more languages supported more capabilities, but I think it's unrealistic to expect all languages to support all, or even most, or even some large fraction of real-world tasks that are out there

You didn't understand my point correctly. Language per se should not support directly, say, bluetooth - because bluetooth will change in an incompatible way. Language could live without a bluetooth library - why not, there is always FFI for dire cases. But the question is about allowing to define a nice API if a need arises. More or less any metaprogramming tool that is not constrained in what it can create would do - those who want to use it, will wrap it in a layer that is nice to use, you can then just incorporate their work.

Common Lisp didn't have any object system in the first edition of the standard; CLOS was prototyped using macros, documented, and then this documentation was basically included in standard. Of couse, macro use could be somewhat more clumsy or more explicit for any reason (make it easier to control overuse, for example) - this is not a problem. The problem is there when you have zero ways to do something - for example, to define a non-trivial iteration pattern.

So, can you give me an example of some Scheme code where the strict typechecks you mentioned are truly helpful ? To me (or, rather, my Schemer's Advocate persona) this sounds inelegant. In Scheme, most entities are pairs, or data structures built of pairs, anyway. Sure, there are a few primitives, but why should I worry about 5 being different from 5.0 or "5" ? That sounds like a job for the interpreter.

Sorry? I was talking about things that help to catch errors. In any small snippet the errors are simple enough to find for this to be unillustrative. It only helps you when you have some kind of wrong assignment in 1K+LOC.