(1) When you contact the author of some code, you will not endear yourself
or win friends by starting by explain that his/her code is "over-complicated",
"inconsistent", "wrong", and buggy.  That is not a smart way to
start the conversation, unless your goal is to piss him/her off.

(2) Most maintainers like for each fix or re-write to be submitted
separately, with separate justification.  A mega-patch with a lot
of unrelated changes is hard to evaluate.   A complete re-write even
more so.

I suggest you read:

http://people.redhat.com/rjones/how-to-supply-code-to-open-source-projects/

(3) If the code is non-idiomatic or over-complicated there might be
reasons for that.  It's a good idea to ask about those reasons before
trying to simplify the code.  Specifically, the code was written
to be maximally portable, only requiring R%RS plus SRFI-0, while
also supporting useful optional features, enabled by cond-expand.

Some aspects / reasons for the complexity:

(a) define-record-type was not in R5RS, so could not be assumed
when the code was originally written in 2005.

In 2015 it may be reasonable to simplify the code by assuming
define-record-type is available.

(b) There is no standard module system we can reasonably
assume.  That is still the case.

(c) R5RS has no standard exception handling mechanism.
At this point it might be reasonable to assume a common
subset of the R6RS/R7RS exceptions.

(4)

> One might say that the best way to move forward is identify the actual
> bugs in it and solve them, not touching the rest so as not to introduce
> any new possible bugs.

Yep.

> But for the time being, I have little motivation to go that route.  It's
> mentally straining for me to go through this type of code.  I wish to
> allocate my time and energy to other things.

That is your choice.  It is also my choice to reject your submission.

(5)

> - It doesn't attempt to record line numbers itself, since test
>    expressions are named anyhow (the expression itself is printed when
>    the name is omitted), so I think it's an insignificant feature.up

I disagree.   Expecting people to come with a unique name for each test
adds a needless hurdle to test-suite development.  In many work-flows
such a name is just useless noise.

In other words, reporting line number of tests (especially failing tests)
is a valuable feature.

> - The output it prints by default is arguably nicer.

Perhaps.  But it's a change, and one that needs to be justified.
I'm used to the current output, and I like it.

> - It doesn't litter your working directory with a log file you didn't
>    ask for and which contains no more than the standard output.

However, in my implementation the log file contains a lot more
information than standard output.  It is very useful in my experience.

> It's only been tested moderately by me but I'm going to go on a limb and
> say that I'm more confident in its overall bug-free-ness than the old
> implementation, because clean code goes a long way.

The innocence and optimism of the young ...

As a general rule, old well-tested ugly code has fewer bugs than
clean freshly-written code.

> The promised list of issues for if you say no, and just want to fix them
> in the existing implementation:

I will look at these more closely.

> In my opinion, most of these bugs could have been avoided if the style
> of the code were more disciplined and simple such that it puts less
> cognitive load on the programmer.

See (1) above.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/