Biff7 fails with, among other things, this:

+  <gnm:Names>
+    <gnm:Name>
+      <gnm:name>dec</gnm:name>
+      <gnm:value>#NAME?</gnm:value>
+      <gnm:position>A1</gnm:position>
+    </gnm:Name>
+    <gnm:Name>
+      <gnm:name>Jan</gnm:name>
+      <gnm:value>#NAME?</gnm:value>
+      <gnm:position>A1</gnm:position>
+    </gnm:Name>
+  </gnm:Names>

xml-sax-read seems to have created these while reading a condition:
              <gnm:Expression0>2000-Jan-1</gnm:Expression0>
              <gnm:Expression1>2020-dec-31</gnm:Expression1>

1. I don't think we should create those.  2. If created, biff7 shouldn't
save them.  3. Note the case difference "dec" vs. "Jan".  I *hope* that
is not a sign that a string is reinterpreted at the time we load the file
because that would mean the interpretation could change depending on locale!

Comment 1 was mistaken, but we have a GUI problem.  When DATE is selected,
the gui should allow the entry of dates.  And the dates should be stored as
expression date(2000,2,3).

The would-be date "2000-Jan-1" was interpreted as a double subtraction with
an placeholder name in the middle.

It looks like xlsx cannot handle the "none" style.  Since it is not
particularly interesting -- it's a no-op -- I will change the test to
avoid those.

With that, the only problem for ods is:

-              <gnm:Expression0>$F$37</gnm:Expression0>
+              <gnm:Expression0>(Sheet1!$F$37)</gnm:Expression0>

In the ODF file we have these two candidates:

<table:content-validation table:name="VAL-0x232bed0" table:allow-empty-cell="false" table:display-list="none" table:base-cell-address="$'Sheet1'.G37" table:condition="of:cell-content-is-whole-number() and cell-content() &gt;= 111">
          <table:error-message table:display="true" table:message-type="stop"/>
        </table:content-validation>


<table:content-validation table:name="VAL-0x233b280" table:allow-empty-cell="false" table:display-list="none" table:base-cell-address="$'Sheet1'.G73" table:condition="of:is-true-formula([.$F$37])">
          <table:error-message table:display="true" table:message-type="stop"/>
        </table:content-validation>

IT is obviously the second. So we seem to read it incorrectly by adding the sheet name to [.$F$37].

We seem to be doing this intentionally:

texpr = oo_expr_parse_str (xin, start, &pp, GNM_EXPR_PARSE_FORCE_EXPLICIT_SHEET_REFERENCES, val->f_type);

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.