Racket and Gerbil are the most interesting Schemes (enough batteries to be productive.) Clojure is the most elegant (amazing primitives) but hate the JVM/want static binaries, so I oscillate between Racket and Common Lisp.
If you could make small, fast static binaries in Clojure, it’d be my only language. Others prefer hosted languages like it: Fennel (Lisp in Lua), Joker (Lisp in Go) etc. Babashka tries to solve it, but it’s not enough. Ciel does the same for Common Lisp.
Reference works:
 Scheme Programming Language  Dybvig
 Common Lisp Nova Spec is better than the HyperSpec
 https://docs.racketlang.org
Seminal articles:

Recursive Functions of Symbolic Expressions and Their Computation by Machine  McCarthy 1960  introduces Lisp

An Unsolvable Problem of Elementary Number Theory  Church 1935  presents lambda calculus. With binary IO it becomes an untyped programming language

Roots of Lisp  Graham

Lisp as the Maxwell’s Equations of Software  Michael Nielsen

Lambda Papers  Steele & Sussman  which developed Scheme

Implementation of Functional Languages Using Custom Hardware and an unrelated talk: https://youtu.be/Z35Tt87pIpg?si=3zvn7DwgQmE8tk7&t=3031, the Reduceron and uLisp

What Gödel Discovered  Parunashvili  explains Gödel’s Incompleteness Theorem with Lispy math

Lisp is not Lambda Calculus  Szmulewicz
Lisp offers many paradigms:
 Type Driven Development  Common Lisp with Coalton, Racket’s higher order dependent contracts
 constraint and logic programming Logic and Computation Intertwined, Little Prover, Little Typer
 Language Driven Development  Beautiful Racket
 Symbolic AI  PAIP, Reasoned Schemer
 Probabilistic Neural Networks  Little Learner
LispE, Lambda Way, Sybilant are fascinating!
Miscellaneous
 http://practicalscheme.net/  aggregates material for production scheme
 Herbert Stoyan  Early Lisp History: 19561959
Quotes
LISP is understood as the model of a functional programming language today. There are people who believe that there once was a clean “pure” language design in the functional direction which was comprised by AIprogrammers in search of efficiency. This view does not take into account, that around the end of the fifties, nobody, including McCarthy himself, seriously based his programming on the concept of mathematical function. It is quite certain that McCarthy for a long time associated programming with the design of stepwise executed “algorithms”.  Herbert Stoyan
On the other side, it was McCarthy who, as the first, seemed to have developed the idea of using funtional terms (in the form of “function calls” or “subroutine calls”) for every partial step of a program. This idea emerged more as a stylistic decision, proved to be sound and became the basis for a proper way of programming  functional progamming (or, as I prefer to call it, functionoriented programming). We should mention here that McCarthy at the same time conceived the idea of logicoriented programming, that is, the idea of using logical formulae to express goals that a program should try to establish and of using the prover as programming language interpreter. To come back to functional programming, it is an important fact that McCarthy as mathematician was familiar with some formal mathematical languages but did not have a deep, intimate understanding of all their details. McCarthy himself has stressed this fact (23). His aim was to use the mathematical formalismus as languages and not as calculi. This is the root of the historical fact that he never took the LambdaCalculus conversion rules as a sound basis for LISP implementation. We have to bear this in mind if we follow now the sequence of events that led to LISP. It is due to McCarthy’s work that functional programming is a usable way of programming today. The main practice of this programming style, done with LISP, still shows his personal mark.  Herbert Stoyan