I think clj-kondo goes a step further in some way. I'm simply thinking of syntactic Spec conforming at read time. It wouldn't include any knowledge of other functions return types or such things.
I imagine something like:
```
(defn foo [a b & options]
...)
(s/fdef foo
:syntax (s/cat :a (s/or symbol? list? int?)
:b (s/or symbol? list? string?)
:options (s/cat :one (s/? (s/cat :opt #{:one} :val (s/or symbol? list? boolean?)))
:two (s/? (s/cat :opt #{:two} :val (s/or symbol? list? #{:fast :slow}))))
(foo 10 (get-b) :one true :two :slow)
```
So like the `fdef` spec takes an additional `:syntax` spec that is just used to conform the syntax of calls to the function. That would be purely syntactical, which is why you see I often allow `(s/or symbol? list? ...)`, probably it be nice to provide a convenient spec here as well for something that is either a symbol or a form or a literal, since all function args will follow this pattern.
But still, this provides a lot of value, and seems quite simple to add, without needing to create any notion of types, and tracking of types across the program. Seems a good fit to Spec. It just allows the same kind of Spec syntax checking macros already get to functions as well. So here it prevents me from passing an unsupported option, from making a typo in the option keywords the function accepts, from passing a wrong enum value to the option, etc. So at least it covers all use of literals.