I don't think there's much point in exposing fatal-error as a procedure, because in general its magical effects (allowing compilers to to generate specialized code and such) will only work if it is treated as a macro.  There is little point in passing it to a not-well-known procedure as an argument, for example, since there is no knowing what it actually does.  Similarly, invoking it with `apply` makes little sense: you don't know what will happen to the irritants if anything, and so they might just as well be a list as an argument sequence.  Unless the compiler provides interprocedural effect tracking, it will not treat fe1 or fe2, defined as (define fe1 fatal-error) and (define (fe2 . args) (apply fatal-error args)), as equivalent to fatal-error.  Lastly, all your natural examples are protected by `unless` in any case, thus making them equivalent to `assume`.

So I think you should reformulate this SRFI to say that `assume` is a syntax keyword, and that it is an error to call it with #f as the value of the first argument, but it returns an unspecified value otherwise.

Here's an interesting example you might want to add:

(define (foo x a b)
  (cond
    ((eq? x 'plus) (+ a b))
    ((eq? x 'minus) (- a b))
    (else (assume #f))))

This definition allows a compiler to treat (foo 'times 3 5) as a compile-time error.

If you do this, then a natural SRFI title is Assume or Assumptions.

-- 
John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
Go, and never darken my towels again!
        --Rufus T. Firefly