> It's your SRFI so you have the final word. I still don't think that it
> is very useful because no guarantees are made at all about the number of
> bits that can be stored in the NaN. With respect to interoperability vs.
> portability, for doing anything non-trivial there does not seem to be
> any portability at all.

Ideally the rationale should suggest at least one potential application
for the SRFI.

> As a compromise, I would like to suggest adding at least the following
> constraint to SRFI 208: R7RS systems that claim to implement IEEE 754
> through the feature flag "ieee-float" and that claim to implement SRFI
> 208 have to implement SRFI 208 with the full IEEE 754 semantics.

Or since R6RS and R7RS have a good library system, offer two libraries:

* (srfi 208 ieee32) -- IEEE float at least 32 bits wide
* (srfi 208 ieee64) -- IEEE float at least 64 bits wide

None, one, or both of these are made available according to hardware.

The following can be used to load them:

(cond-expand ((library (srfi 208 ieee32))
               (import  (srfi 208 ieee32)))
              ((library (srfi 208 ieee64))
               (import  (srfi 208 ieee64))))

An alternative is to export a payload-width constant.

Do non-IEEE floating point formats distinguish between quiet and
signaling NaN?

Otherwise LGTM, and good C code in the implementation! Many/most of the
C functions could probably be declared `static`, which makes modern
compilers inline them and probably omit a standalone version of them.