Thank you for your work on this proposal.

Re:
==============================
2. Many implementations widen real arguments to have a +0i (or +0.0i)
imaginary part when multiplying them with complex numbers. This causes
some unfortunate issues, such as (* 1 z) and (* +i (* +i (* +i (* +i
z)))) not being the identity when passed a complex number with
infinities or NaNs. (This is related to, but distinct from, the fact
that it is unspecified whether (* 0 +inf.0) returns NaN or 0.)

     My solution to this in a future draft is to spell out real-complex,
real-imaginary, and imaginary-complex arithmetic in a similar way to
Annex G of the current C standard.
<https://port70.net/~nsz/c/c23/n3220.pdf> pg. 541.

     This will necessitate defining imaginary? and strictly-imaginary? as
predicates.
==============================
I recommended 28 years ago at the Baltimore Scheme Workshop that (* 0
<anything>) (0 === exact zero) be 0 (exact zero).  The ansatz is that in
nonstandard analysis (real) 0 times anything (including an unbounded
nonstandard real) is (real) 0.  I'll include my proposal in a separate
email.

If you have this rule and allow mixed exactness complex numbers, then
the problems of (* +i (* +i (* +i (* +i z)))) not being z goes away.
You don't need to define *+i and *-i in the sample implementation.  You
don't need separate definitions of "real-complex, real-imaginary, and
imaginary-complex arithmetic".

In fact, I'd recommend that the standard be specified so that
implementations must behave *as if* they have mixed exactness arithmetic
and (* 0 anything) => 0, even if they don't.

Similarly if you define real? to mean (and (zero? x) (exact? x)), you
don't need strictly-real?, strictly-imaginary?, etc., etc.  (PS:  I
think the more common mathematical term is purely-imaginary.)

I think we're piling complexity on complexity to accommodate what I
consider to be some implementations' limitations (no mixed-exactness
complex numbers).

To add what I hope will be helpful comments to this kvetch:

1.  I believe the condition on (angle z) in the definition of log should
be -\pi < angle z \leq \pi, i.e, the first inequality should be strict.

2.  I believe that you should specify the branch cut for sqrt, too, then
the branch cuts of the inverse trigonometric and inverse hyperbolic
functions are well defined.

3.  I would recommend allowing (using 0 and 1 to mean exact 0 and exact 1):

(sinh 0) => 0
(cosh 0) => 1
(tanh 0) => 0
(asinh 0) => 0
(acosh 1) => 0
(atanh 0) => 0

Perhaps you want to add

(atanh -1) => error

More generally, if an implementation allows mixed exactness complex
numbers and an implementation can determine that the imaginary or real
part of a result is exact, then it should be allowed to return a result
with exact real or imaginary part, e.g.,

  (atanh -1.0i)  => -.7853981633974483i

4.  I think the signs of the real part of the result are mistaken here:

(atanh 1.0+0.0i) ⇒ -inf.0+.7853981633974483i
(atanh 1.0-0.0i) ⇒ -inf.0-.7853981633974483i
(atanh -1.0+0.0i) ⇒ +inf.0+.7853981633974483i
(atanh -1.0-0.0i) ⇒ +inf.0-.7853981633974483i

This wasn't corrected in Gambit GitHub head until March 12, and it's not
available in a release yet, sorry.

5.  I'm not really clear about the motivation for having round-away; is
(round x) specified to round to even (I forget)?  What about round-up,
round-down, round-to-zero, do we want those, too?

Brad