1. Is there a specific form for testing raised exceptions? Or should
testing that an expression raises an exception just use `guard` or
`with-exception-handler`?

2. SRFI 229 and SRFI 259 implement something equivalent to Guile
procedure properties. You should mention them in the "Implementation"
section.

3. Mutable parameter objects are not portable and APIs that use it are
difficult to port to immutable-parameter-object systems. I believe that
should be changed to something else. (You mentioned in another thread
that it could be a fluid or something else, but that would make it
difficult for portable code to `parameterize` it.)

    A portable way to fix this would be to export `(test-runner*)`
without the mutation API, and then export `(set-current-test-runner*!
obj)`. An immutable parameter object system would mutate a box, while a
mutable-parameter-object system like Guile would just do:

    (define (set-current-test-runner*! obj)
      (test-runner* obj))

    An implementation of the SRFI could then implement `(test-runner*)`
with the mutation API specified right now, as a compatible extension.

4. Is there a need to have a predicate for suite thunks? Could those
also be an association list like the other objects? This would remove
the dependency on procedure properties. It would probably require a
`run-test-thunk` procedure or something like that, but that minor
inconvenience would be worth it for 100% portability for R6RS and
R7RS-Small.

    An alternative to test-thunks being alists is that they could be
either records or lambdas with a procedure property. That way code
written for Guile that assumes test-thunks are procedures would still
work, while portable code for R6RS and R7RS-Small would use
`run-test-thunk` or similar to invoke the thunk in a record type. Of
course if they are no longer guaranteed to be procedures, the name
should be changed.

-- Peter McGoron