>> (raise-foreign-error alist)
>> (raise-continuable-foreign-error alist)

> This also runs against my desire to keep the top level, first class
> part of the API as small as possible, and having each entry fan out
> as needed.

I don't understand this. (raise-foreign-error alist continuable?) takes
two arguments, and the latter one is usually just #f (see below). For
the user of SRFI 198, wouldn't it be simplest if no #f argument is
needed? We could also make it an optional argument.

More generally, do extra top-level procedures make an API more
complicated compared to extra arguments? I would argue with Rich Hickey
and Alan Perlis that an API can have any number of mutually independent
procedures operating on the same data structure without complicating the
API. It's only interdependent (i.e. non-orthogonal, coupled or
"complected") things that increase complexity. Based on this reasoning,
an extra procedure and an extra argument are equally (non-)complex ways
of adding the same feature. An extra procedure has the advantage that
its name says what it does, whereas you need to remember what an extra
argument does by it position. Keyword arguments would ameliorate this
somewhat, but we don't have those (at least not yet).

> I'm making the assumption that most raised errors will
> be non-continuable; if correct,

That assumption is almost certain to be correct.

> this is as simple as I can make it
> for those writing code that uses SRFI 198.

IMHO the alternatives are equally simple, but a named procedure gives an
extra "affordance" (UI designer speak for something visible or tangible
that guides user behavior in the right direction) compared to an unnamed
argument.