I tried running your version of the test.  It turns out it is
not "pure R7RS", at least not by itself, as it depends on functions
from srfi-1, srfi-13, and srfi-28 (format), a least.

Your runner doesn't print anything until the very end.  I think
it is better to print out the results as you go, in case of some
uncaught error crashing the test.

Having the default runner print out a PASS line for every passing
test is needlessly verbose.  That is why my runner only prints out
unexpected results plus a summary; the details, including passing
tests, are in the log file.

> I agree [line numbers are] quite convenient ...., but I found the trade-off
> between the offered convenience and the complexity added to the code to
> be in favor of removing the feature.

I disagree with this trade-off.  Line-number reporting isn't quite
essential, but it makes using the framework much more friendly.
And if the feature is already implemented and works (at least on
Kawa, Guile-2, and [some old version of] mzscheme) it would be
a shame to remove a working useful feature.

> - On line 758 which defines 'test-assert', the 'tname' argument to the
>    macro is evaluated by being bound to the variable 'name', but later
>    'tname' is used again and not 'name', and that in a quoted list, so
>    this 'test-assert' only takes literals for the test name.  (This
>    breaches the specification which says it is evaluated.)  This bug is
>    partly hidden by the fact that it's in the else branch of a
>    cond-expand.
>
> - On line 704, the other definition of 'test-assert' (for Kawa,
>    MzScheme, and Guile 2), the same mistake of binding 'name' to the
>    evaluation of 'tname', but then using 'tname' instead of 'name'
>    occurs.  This time 'tname' is *not* in a quoted list so in effect it
>    will be evaluated twice (breaching the spec), though this is a minor
>    bug.  It's noteworthy that there's no particular reason it's quoted in
>    one definition and not the other (the other just uses 'cons'); it's
>    simply the code being inconsistent in its style.

Yes, that is a buglet, plus there are some inconsistencies. I attached a fix.

I'll look at your other issues later.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/