I suggest resolving this as follows.

1. In DM 1.1, perhaps in a new subsection of 2.6, state that: the xs:float and xs:double data types as used in DM have the same value space as in XSD 1.1, specifically they include both negative and positive zero, and in this respect they differ from XSD 1.0. To accommodate this difference, when converting from an xs:string to an xs:float or xs:double, it is implementation-defined whether the lexical value "-0" (and similar forms such as "-0.0") convert to negative zero or to positive zero in the value space.

2. In FO 1.1:

2.1 In 4.1 (numeric types), change the Note to explain the treatment of negative zero

2.2 In 14.4.4 (fn:min) change the explanation of the example that uses negative zero

2.3 In 17.1 (constructor functions) change the explanation of how the constructor functions for xs:float and xs:double handle negative zero: specifically, that the XSD 1.1 mapping of "-0" to negative zero is preferred, but that mapping the lexical representation "-0" to positive zero is acceptable for compatibility with XSD 1.0 processors.

2.4 In 18.1.3.1 (casting to xs:float) change the Note likewise

2.5 In 18.1.3.2 (casting to xs:double) change the Note likewise

Note that the original problem identified in bug #9605 with the wording of fn:round has already been fixed as a side-effect of the rewriting of the rules for this function when the optional second argument was introduced.

The proposal in comment #1 was accepted, with the amendment that we should recommend that string-to-double conversion converts "-0" to negative zero, while permitting conversion to positive zero where necessary e.g. where constrained by an XSD 1.0 PSVI implementation.

As the originator was present at the meeting I am marking this as closed.