Issues for the next revision of 754

The 754 working group identified certain issues as potentially problematic
in the future, although no issues have been raised by users so far.
These issues might be considered in the next 754 revision, referred to
in minutes as 754-2029.   Examples:

== 3.7 extended and extendable formats

Harthcock: Is decimalCharachterSequence an "arithmetic format"?

754 says
 
 arithmetic format: A floating-point format that can be used to represent
 floating-point operands or results for the operations of this standard.
 
decimalCharacterSequence is an operand or result of the operations in 5.4.2,
but we didn't mean to include it as a floating-point format, as we never
intended it to be an operand or result of any of the other standard operations.
That's not explicit, and there is no definition of
"floating-point format".
We certainly meant to only include formats for which all the operations
of the standard can be defined.
 
One might argue that
a decimalCharacterSequence might be a 3.7 extended or extendable format.
Another might argue that that's a good reason for getting rid of 3.7.

== 7.1 exception flags propagation upward from invoked functions -
how much freedom do language standards have to regulate that?

  "On return from or termination of an invoked function, the flags standing 
  in an invoking function are the flags that were standing in the function 
  at the time of return or termination."

 Suggestions for rewording from Nima Badizadegan

 1) "Unless otherwise specified in a language standard or subprogram
definition, on return from or termination of an invoked function, flags are
passed to the invoking function."

 2) "Unless otherwise specified in a language standard or subprogram
definition, flags are passed from an invoked function to the invoking
function on return from or termination of the invoked function."

 Thus 1) is closer to the original text of the clause, 
 but 2) is less awkward.

== 8.1 sub-exceptions - what happens with FMA(sNaN + 0 X inf), not to
mention reduction operations?   A standard operation can only raise
one exception, but can it raise multiple sub-exceptions?
 
== 9.4 reduction operations - what exactly is the minimum quality requirement
 to conform in terms of avoiding intermediate exceptions?
 
 "Otherwise, sums are computed in a manner that avoids overflow 
 or underflow with no avoidable intermediate exception conditions 
 in the calculation and the final result is determined from 
 that intermediate result."