Hello Antero,

> It might be good to explicitly say if (case-lambda-checked) handles
> multiple dispatch. The sample implementation does not - it would have to
> implement a different version of case-lambda.

The introduction of the SRFI says that none of the spec-ed primitives
handle type dispatching. And there's a dedicated section comparing match
and early draft check-case primitive which taps into dispatch problem.

> It could be valuable for performance optimization, especially for the
> numeric tower. But changing any behavior based on type checks can be
> unclear.

So my reasoning here is: predicate/type dispatching belongs to the
object system, rather than assertion system. Given that this SRFI is
closer to assertions than OO systems, dispatching feels quite off for
it.

> Maybe let the implementation decide, and/or connect it to a feature
> identifier? For example, specify that implementations must have the
> type-checking-dispatch feature if they dispatch, and
> type-checking-coercion if they coerce?

This is a good suggestion, but implementations are likely already
optimizing their object systems, so it makes no sense coming up with a
different mechanism doing the same thing.

I'll integrate this reasoning into the SRFI text. Thanks for
highlighting this confusion!

Best of luck,
--
Artyom Bologov
https://aartaka.me