Common Lisp's type system isn't optional. The language is strongly typed. Type goes away (in a sense) when you add declarations. That is to say, if you tell Lisp that, say, some variable contains a fixnum, then (in code compiled with safety 0) it just believes your declaration, and it's up to you to ensure that it's not a lie (else the behavior is undefined). The type system isn't optional in any other sense.
It's optional for an implementation to provide static checks and optimizations based on type, which is different. "Static type" and "type" are not synonyms.
Common Lisp code is safe by default; you can't use an object of type X as if it were one of type Y.
A spec that says adding a fixnum to a string produces a possibly-runtime error isn't a type system, it's just a particular instance behaviour. Types are by definition associated to terms in a language.
(That isn't to say that that kind of runtime behaviour isn't valuable or doesn't provide (some of) the same functionality as a type system. But it's not what the word "type" means).
> Types are by definition associated to terms in a language.
This is true, within a particular paradigm, which isn't the be-all and end-all of what "type" means in computer science.
All kinds of things are type. For instance, "JPEG file" or "alphanumeric character" are both type terms.
You don't get to dictate to everyone one narrow definition of a term that has an obviously broad applicability in numerous contexts.
If we are discussing Common Lisp, and you want to get properly pedantic about what "type" means, the way you can do that is to look up its definition in the ANSI CL glossary, which says:
"type n. 1. a set of objects, usually with common structure, behavior, or purpose."
Or you can use it in a broader way which is compatible with this concept.
If you insist that it means something else which is not compatible with the glossary definition, and you still want to talk about Lisp, then I'm afraid it's not productive; you are more interested in engaging in a conflict about word semantics: which "camp" gets to "own" the ideologically precious word, such as "type".
Usually how we can resolve that conflict is to split our vocabulary into different words. You can have "type", I don't need it; I will call it this other thing that the CL glossary refers to "genus". Now type can be the property of a syntactic term in a program, and genus refers to sets of objects which have something in common.
I'm mostly interested in genus systems, and type systems in their context (agreement between the type of a program term, and the genus of the run-time thing it operates on).
I don't think Lisp could even be said to have a genus system - to have a "system" for dealing with sets of objects implies having a way to talk about those sets, do set operations (intersection/union/product) etc.
But in any case, any genus-but-not-type system is irrelevant to my original point: that when writing an x86-64 assembler in lisp (as an embedded DSL), any enforcement of restrictions at compile time would have to be expressed as ad-hoc macros, because there is no (language-standard) type system in which to declare them.
It's optional for an implementation to provide static checks and optimizations based on type, which is different. "Static type" and "type" are not synonyms.
Common Lisp code is safe by default; you can't use an object of type X as if it were one of type Y.