Some features of Common Lisp or other Lisps will be absent in Spark, some things will be harder to do than Common Lisp or even other Lisps or other non-Lisp programming languages, and some things will not work as expected at first (bugs, etc.). A lot of it will be caused due to the fact that the primary author of this document does not consider himself a Scheme expert (and is very far from being a Common Lisp expert) and just likes Lisp, Perl 5 and other languages enough to want to promote them.
As a result, some estoric features of the popular Lisp languages today or some languages that he has not fully investigated yet, won’t be available at first. This is expected given his ignorance, enthusiasm and anxiety to get something out of the door first.
While he would still be interested in learning about whatever core library or meta-programmatic features other languages have that may prove useful for the core Spark language (or alternatively cool APIs that you think should be ported to Spark). But he has little patience to learn entire languages “fully” (if learning any non-trivial language fully is indeed possible) before starting to work on Spark. And often ignorance is a virtue.
So the first versions of Spark will still have some room for improvement. Most of it may hopefully be solvable using some meta-syntactic or meta-programming user-land libraries (as is often the case for Lisps and other dynamic languages). As for the rest, we could consider them bad design decisions that still add to the language’s colour and make it a bit more interesting to program in than a 100% perfect language. Sometimes perfection is in imperfection.