I believe this is where Common Lisp got it right and scheme got it wrong. The scheme designers wanted a more pure language when often, the dirty imperative method is desirable. Common lisp has many features to make programming of real, large-scale projects easy (a great example is looping constructs which are often more obvious and easier than the more 'pure' tail recursion preference of scheme).

Scheme has plenty of dirty imperative methods, if you want. Their names end with `!`, like `set!` to mutate a variable. In most cases it's cleaner to be purely functional, but it's not required.

Predicates end with `?`, like `equal?`.

This naming and consistency makes it easier to learn Scheme.

What makes Common Lisp more practical is libraries. Hairy and crufty some may be, but many of them, and many of good quality. You know the old saying about how X is a badly implemented version of half of Common Lisp.

The Scheme-descendant Racket is, however, plenty practical in this regard.

I really don't like the Common Lisp naming and the 2-space nature of the language makes this even worse. The conflict of the implementors appears in many places. I like many things about scheme, but I won't whitewash it's problems.

Non-standard, non-portable racket libraries aren't the answer to scheme's basic nature (though I believe r7rs-large will solve a lot of these issues). More serious dealbreakers in my work are the lack of declare, no built-in OOP, and no spec for optional and keyword parameters.

Scheme has other issues too such as the inability to turn off continuations (they are great in some situations, but can cause performance issues and specifically cause increased memory usage).

Racket's extensive collection of libraries aren't meant to answer anything about Scheme -- they're for Racket. That's why we changed the name.

Racket is, however, a great answer to "is there a Lisp that's both conceptually consistent and has lots of libraries".