LispKit: framework for Lisp-based extension/scripting languages for macOS apps

The standard library and built-in forms that actually define the language semantics?

Macros is the most glaring omission that I can see.

Scheme's closest equivalents are neat academic exercises, but I don't consider them complete macro systems.

While it's true folks argue that it doesn't really matter (evidence: the section 'Arguments why it doesn't matter' on that page), I'll counter-argue that they're wrong. Scheme simply isn't the same language as Lisp. That's okay: the entire world doesn't need to standardise on a single language (although if it's going to, Lisp would be preferable to Scheme).

And, honestly, the arguments that it doesn't matter presented on that page are pretty weak. 'It's a pointless distraction' is an assertion, not an argument. Scheme and Lisp are different; they have different philosophies and they solve the same problems in different ways; recognising those differences is recognising the facts; ignoring them is simply ignoring reality. 'The benefits of choice far outweigh the disadvantages of redundant/wasted development work on two incompatible platforms' is clearly, I believe, falsified by the experience of the last couple of decades. When I think of the work which went into Racket (originally a Scheme, but now its own thing) and Clojure, I think of how much better Lisp could have been if that effort had instead been spent on it (and aficionados of either of those languages could say the same thing about effort spent on the other, on Lisp & on other Lisp-like languages).

Ctrl+F "dialect" makes my point.

Common Lisp is a successor ro Maclisp, which was a successor for the original Lisp implementation. Common Lisp was designed such that the old code can be ported to a modernized version of Lisp. This code moved from Lisp 1.5 to Maclisp to ZetaLisp and to Common Lisp.

Scheme OTOH has its own code bases, its own libraries, its own standards, its own books, its own community.

It is a Lisp, but that has become more or less meaningless for practical work. Being 'a Lisp" means practically very little. It's just a name with an unclear definition and less and less practical value. Thus 'a Lisp' means mostly an unspecified bunch of dialects which are in practical terms mostly unrelated.

I prefer a stronger definition, where Lisp means those dialects and their implementation which actually share code, books, libraries, tools.

Otherwise people get the impression of some compatibility, which in real life isn't given.

It's like a family member, which used to carry your name, but now has left the house and has its own life.