IMSEC

Microsoft publishes '=IMSEC("4+3i")' with the result -0.0652940278579471-0.0752249603027732i. Derived independently with mpmath at 40 digits: sec(z) = 1/cos(z), with cos(x+yi) = cos(x)cosh(y) - i*sin(x)sinh(y). At 40 digits 1/cos(4+3i) = -0.06529402785794704644515821 - 0.07522496030277322686557715i. Cross-check on the modulus: |cos(4+3i)|^2 = 100.785068044323640479, and 1/|cos| = 0.09961..., consistent with |sec| = sqrt(0.0652940278579470^2 + 0.0752249603027732^2) = 0.0996136.... EXCEL'S COMPLEX-STRING FORMAT, which this corpus derives rather than assumes: a result is rendered as the real part, then the sign, then the imaginary coefficient followed by the suffix, with each part printed to at most 15 significant digits and trailing zeros stripped; a zero real part is omitted entirely, a zero imaginary part reduces the result to a bare real number, and an imaginary coefficient of exactly 1 or -1 prints as "i" / "-i" with no digit. That rule was written as a formatter in Python by batch D and validated against seven independently published Microsoft strings (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP, IMLN); batch E re-ran that validation and then extended it, reproducing THIRTEEN MORE published Microsoft strings byte for byte (IMLOG10, IMLOG2, IMPOWER, both IMPRODUCT examples, IMSEC, IMSECH, IMSIN, IMSINH, IMSQRT, IMSUB, IMSUM, IMTAN) before predicting anything -- twenty published strings in all. ONE REFINEMENT BATCH E HAD TO MAKE: batch D fed the formatter the EXACT value computed at 40 digits, which happened to render identically to the IEEE double for all seven of its strings. That is not true here. A spreadsheet engine holds a double, not the exact value, and two of this batch's published strings only come out right if the derivation rounds to the nearest double BEFORE formatting: IMPOWER("2+3i",3) is exactly -46+9i in exact arithmetic but Microsoft publishes -46+9.00000000000001i, which is what exp(3*ln(2+3i)) gives in double precision; and IMSEC("4+3i") has an exact real part of -0.06529402785794704644..., whose 15-digit rounding ends ...47, while the correctly-rounded double -0.065294027857947051 rounds to ...471, which is what Microsoft publishes. So every value in this batch is derived exactly with mpmath at 40 digits, THEN rounded to the double an engine actually holds, THEN formatted. String results are compared exactly, so a formatting-only difference (a trailing zero, "1i" for "i", a different digit count) fails the case and is recorded as its own divergence class, separate from a wrong numeric value. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMSEC is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMSEC, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMSEC here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMSEC, COM.MICROSOFT.IMSEC, ORG.OPENOFFICE.IMSEC and _xlfn.ORG.OPENOFFICE.IMSEC are all #NAME? on every build, while the UNPREFIXED IMSEC(...) evaluates on every build and returns exactly the string asserted here, byte for byte. So LibreOffice implements IMSEC, and its OOXML import simply has no mapping for the _xlfn.IMSEC token Excel writes -- meaning a workbook saved by Excel that uses IMSEC arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is the same class batch D recorded for IMCOSH, IMCOT, IMCSC and IMCSCH. It is recorded as its own divergence class rather than as an ordinary unsupported-function result. CROSS-VERSION DRIFT FOUND HERE, in the last digit. Under the unprefixed name the four builds do NOT agree: 24.2.0.3 and 24.8.7.2 return -0.0652940278579471-0.0752249603027732i, which is Microsoft's published string byte for byte, while 25.2.0.3 and 25.8.7.3 return -0.065294027857947-0.0752249603027732i -- one significant digit shorter. Neither is a wrong value: the exact real part is -0.06529402785794704644515821, the correctly-rounded double is -0.065294027857947051 (whose 15-digit rendering ends ...471, matching Excel and the older builds) and the newer builds hold the adjacent double -0.065294027857947037 (whose 15-digit rendering ends ...47). The two doubles differ by one unit in the last place, about 1.4e-17, and straddle a 15-digit rounding boundary, which is the only reason the STRINGS differ at all. Recorded as a precision/formatting difference, not as a value error -- but it is a real regression in byte-for-byte agreement with Excel, and because IM* results are strings, an exact-match comparison in a spreadsheet would flag it.

Excel documents: "If inumber is a logical value, IMSEC returns the #VALUE! error value." A deliberate refusal to coerce -- TRUE becomes 1 in nearly every other numeric context. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMSEC is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMSEC, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMSEC here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMSEC, COM.MICROSOFT.IMSEC, ORG.OPENOFFICE.IMSEC and _xlfn.ORG.OPENOFFICE.IMSEC are all #NAME? on every build, while the UNPREFIXED IMSEC(...) evaluates on every build. So LibreOffice implements IMSEC, and its OOXML import simply has no mapping for the _xlfn.IMSEC token Excel writes -- meaning a workbook saved by Excel that uses IMSEC arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is the same class batch D recorded for IMCOSH, IMCOT, IMCSC and IMCSCH. It is recorded as its own divergence class rather than as an ordinary unsupported-function result.

Excel documents: "If inumber is a value that is not in the x+yi or x+yj text format, IMSEC returns the #NUM! error value." Note this is #NUM!, not the #VALUE! that the logical-value clause on the same page specifies -- the two malformed-input branches are documented as returning DIFFERENT errors, which is why both are asserted. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMSEC is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMSEC, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMSEC here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMSEC, COM.MICROSOFT.IMSEC, ORG.OPENOFFICE.IMSEC and _xlfn.ORG.OPENOFFICE.IMSEC are all #NAME? on every build, while the UNPREFIXED IMSEC(...) evaluates on every build. So LibreOffice implements IMSEC, and its OOXML import simply has no mapping for the _xlfn.IMSEC token Excel writes -- meaning a workbook saved by Excel that uses IMSEC arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is the same class batch D recorded for IMCOSH, IMCOT, IMCSC and IMCSCH. It is recorded as its own divergence class rather than as an ordinary unsupported-function result.

Microsoft publishes '=IMSEC("4+3i")' with the result -0.0652940278579471-0.0752249603027732i. Derived independently with mpmath at 40 digits: sec(z) = 1/cos(z), with cos(x+yi) = cos(x)cosh(y) - i*sin(x)sinh(y). At 40 digits 1/cos(4+3i) = -0.06529402785794704644515821 - 0.07522496030277322686557715i. Cross-check on the modulus: |cos(4+3i)|^2 = 100.785068044323640479, and 1/|cos| = 0.09961..., consistent with |sec| = sqrt(0.0652940278579470^2 + 0.0752249603027732^2) = 0.0996136.... EXCEL'S COMPLEX-STRING FORMAT, which this corpus derives rather than assumes: a result is rendered as the real part, then the sign, then the imaginary coefficient followed by the suffix, with each part printed to at most 15 significant digits and trailing zeros stripped; a zero real part is omitted entirely, a zero imaginary part reduces the result to a bare real number, and an imaginary coefficient of exactly 1 or -1 prints as "i" / "-i" with no digit. That rule was written as a formatter in Python by batch D and validated against seven independently published Microsoft strings (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP, IMLN); batch E re-ran that validation and then extended it, reproducing THIRTEEN MORE published Microsoft strings byte for byte (IMLOG10, IMLOG2, IMPOWER, both IMPRODUCT examples, IMSEC, IMSECH, IMSIN, IMSINH, IMSQRT, IMSUB, IMSUM, IMTAN) before predicting anything -- twenty published strings in all. ONE REFINEMENT BATCH E HAD TO MAKE: batch D fed the formatter the EXACT value computed at 40 digits, which happened to render identically to the IEEE double for all seven of its strings. That is not true here. A spreadsheet engine holds a double, not the exact value, and two of this batch's published strings only come out right if the derivation rounds to the nearest double BEFORE formatting: IMPOWER("2+3i",3) is exactly -46+9i in exact arithmetic but Microsoft publishes -46+9.00000000000001i, which is what exp(3*ln(2+3i)) gives in double precision; and IMSEC("4+3i") has an exact real part of -0.06529402785794704644..., whose 15-digit rounding ends ...47, while the correctly-rounded double -0.065294027857947051 rounds to ...471, which is what Microsoft publishes. So every value in this batch is derived exactly with mpmath at 40 digits, THEN rounded to the double an engine actually holds, THEN formatted. String results are compared exactly, so a formatting-only difference (a trailing zero, "1i" for "i", a different digit count) fails the case and is recorded as its own divergence class, separate from a wrong numeric value. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMSEC is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMSEC, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMSEC here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMSEC, COM.MICROSOFT.IMSEC, ORG.OPENOFFICE.IMSEC and _xlfn.ORG.OPENOFFICE.IMSEC are all #NAME? on every build, while the UNPREFIXED IMSEC(...) evaluates on every build and returns exactly the string asserted here, byte for byte. So LibreOffice implements IMSEC, and its OOXML import simply has no mapping for the _xlfn.IMSEC token Excel writes -- meaning a workbook saved by Excel that uses IMSEC arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is the same class batch D recorded for IMCOSH, IMCOT, IMCSC and IMCSCH. It is recorded as its own divergence class rather than as an ordinary unsupported-function result. CROSS-VERSION DRIFT FOUND HERE, in the last digit. Under the unprefixed name the four builds do NOT agree: 24.2.0.3 and 24.8.7.2 return -0.0652940278579471-0.0752249603027732i, which is Microsoft's published string byte for byte, while 25.2.0.3 and 25.8.7.3 return -0.065294027857947-0.0752249603027732i -- one significant digit shorter. Neither is a wrong value: the exact real part is -0.06529402785794704644515821, the correctly-rounded double is -0.065294027857947051 (whose 15-digit rendering ends ...471, matching Excel and the older builds) and the newer builds hold the adjacent double -0.065294027857947037 (whose 15-digit rendering ends ...47). The two doubles differ by one unit in the last place, about 1.4e-17, and straddle a 15-digit rounding boundary, which is the only reason the STRINGS differ at all. Recorded as a precision/formatting difference, not as a value error -- but it is a real regression in byte-for-byte agreement with Excel, and because IM* results are strings, an exact-match comparison in a spreadsheet would flag it.

Excel documents: "If inumber is a logical value, IMSEC returns the #VALUE! error value." A deliberate refusal to coerce -- TRUE becomes 1 in nearly every other numeric context. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMSEC is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMSEC, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMSEC here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMSEC, COM.MICROSOFT.IMSEC, ORG.OPENOFFICE.IMSEC and _xlfn.ORG.OPENOFFICE.IMSEC are all #NAME? on every build, while the UNPREFIXED IMSEC(...) evaluates on every build. So LibreOffice implements IMSEC, and its OOXML import simply has no mapping for the _xlfn.IMSEC token Excel writes -- meaning a workbook saved by Excel that uses IMSEC arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is the same class batch D recorded for IMCOSH, IMCOT, IMCSC and IMCSCH. It is recorded as its own divergence class rather than as an ordinary unsupported-function result.

Excel documents: "If inumber is a value that is not in the x+yi or x+yj text format, IMSEC returns the #NUM! error value." Note this is #NUM!, not the #VALUE! that the logical-value clause on the same page specifies -- the two malformed-input branches are documented as returning DIFFERENT errors, which is why both are asserted. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMSEC is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMSEC, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMSEC here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMSEC, COM.MICROSOFT.IMSEC, ORG.OPENOFFICE.IMSEC and _xlfn.ORG.OPENOFFICE.IMSEC are all #NAME? on every build, while the UNPREFIXED IMSEC(...) evaluates on every build. So LibreOffice implements IMSEC, and its OOXML import simply has no mapping for the _xlfn.IMSEC token Excel writes -- meaning a workbook saved by Excel that uses IMSEC arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is the same class batch D recorded for IMCOSH, IMCOT, IMCSC and IMCSCH. It is recorded as its own divergence class rather than as an ordinary unsupported-function result.

Microsoft publishes '=IMSEC("4+3i")' with the result -0.0652940278579471-0.0752249603027732i. Derived independently with mpmath at 40 digits: sec(z) = 1/cos(z), with cos(x+yi) = cos(x)cosh(y) - i*sin(x)sinh(y). At 40 digits 1/cos(4+3i) = -0.06529402785794704644515821 - 0.07522496030277322686557715i. Cross-check on the modulus: |cos(4+3i)|^2 = 100.785068044323640479, and 1/|cos| = 0.09961..., consistent with |sec| = sqrt(0.0652940278579470^2 + 0.0752249603027732^2) = 0.0996136.... EXCEL'S COMPLEX-STRING FORMAT, which this corpus derives rather than assumes: a result is rendered as the real part, then the sign, then the imaginary coefficient followed by the suffix, with each part printed to at most 15 significant digits and trailing zeros stripped; a zero real part is omitted entirely, a zero imaginary part reduces the result to a bare real number, and an imaginary coefficient of exactly 1 or -1 prints as "i" / "-i" with no digit. That rule was written as a formatter in Python by batch D and validated against seven independently published Microsoft strings (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP, IMLN); batch E re-ran that validation and then extended it, reproducing THIRTEEN MORE published Microsoft strings byte for byte (IMLOG10, IMLOG2, IMPOWER, both IMPRODUCT examples, IMSEC, IMSECH, IMSIN, IMSINH, IMSQRT, IMSUB, IMSUM, IMTAN) before predicting anything -- twenty published strings in all. ONE REFINEMENT BATCH E HAD TO MAKE: batch D fed the formatter the EXACT value computed at 40 digits, which happened to render identically to the IEEE double for all seven of its strings. That is not true here. A spreadsheet engine holds a double, not the exact value, and two of this batch's published strings only come out right if the derivation rounds to the nearest double BEFORE formatting: IMPOWER("2+3i",3) is exactly -46+9i in exact arithmetic but Microsoft publishes -46+9.00000000000001i, which is what exp(3*ln(2+3i)) gives in double precision; and IMSEC("4+3i") has an exact real part of -0.06529402785794704644..., whose 15-digit rounding ends ...47, while the correctly-rounded double -0.065294027857947051 rounds to ...471, which is what Microsoft publishes. So every value in this batch is derived exactly with mpmath at 40 digits, THEN rounded to the double an engine actually holds, THEN formatted. String results are compared exactly, so a formatting-only difference (a trailing zero, "1i" for "i", a different digit count) fails the case and is recorded as its own divergence class, separate from a wrong numeric value. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMSEC is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMSEC, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMSEC here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMSEC, COM.MICROSOFT.IMSEC, ORG.OPENOFFICE.IMSEC and _xlfn.ORG.OPENOFFICE.IMSEC are all #NAME? on every build, while the UNPREFIXED IMSEC(...) evaluates on every build and returns exactly the string asserted here, byte for byte. So LibreOffice implements IMSEC, and its OOXML import simply has no mapping for the _xlfn.IMSEC token Excel writes -- meaning a workbook saved by Excel that uses IMSEC arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is the same class batch D recorded for IMCOSH, IMCOT, IMCSC and IMCSCH. It is recorded as its own divergence class rather than as an ordinary unsupported-function result. CROSS-VERSION DRIFT FOUND HERE, in the last digit. Under the unprefixed name the four builds do NOT agree: 24.2.0.3 and 24.8.7.2 return -0.0652940278579471-0.0752249603027732i, which is Microsoft's published string byte for byte, while 25.2.0.3 and 25.8.7.3 return -0.065294027857947-0.0752249603027732i -- one significant digit shorter. Neither is a wrong value: the exact real part is -0.06529402785794704644515821, the correctly-rounded double is -0.065294027857947051 (whose 15-digit rendering ends ...471, matching Excel and the older builds) and the newer builds hold the adjacent double -0.065294027857947037 (whose 15-digit rendering ends ...47). The two doubles differ by one unit in the last place, about 1.4e-17, and straddle a 15-digit rounding boundary, which is the only reason the STRINGS differ at all. Recorded as a precision/formatting difference, not as a value error -- but it is a real regression in byte-for-byte agreement with Excel, and because IM* results are strings, an exact-match comparison in a spreadsheet would flag it.

Excel documents: "If inumber is a logical value, IMSEC returns the #VALUE! error value." A deliberate refusal to coerce -- TRUE becomes 1 in nearly every other numeric context. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMSEC is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMSEC, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMSEC here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMSEC, COM.MICROSOFT.IMSEC, ORG.OPENOFFICE.IMSEC and _xlfn.ORG.OPENOFFICE.IMSEC are all #NAME? on every build, while the UNPREFIXED IMSEC(...) evaluates on every build. So LibreOffice implements IMSEC, and its OOXML import simply has no mapping for the _xlfn.IMSEC token Excel writes -- meaning a workbook saved by Excel that uses IMSEC arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is the same class batch D recorded for IMCOSH, IMCOT, IMCSC and IMCSCH. It is recorded as its own divergence class rather than as an ordinary unsupported-function result.

Excel documents: "If inumber is a value that is not in the x+yi or x+yj text format, IMSEC returns the #NUM! error value." Note this is #NUM!, not the #VALUE! that the logical-value clause on the same page specifies -- the two malformed-input branches are documented as returning DIFFERENT errors, which is why both are asserted. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMSEC is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMSEC, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMSEC here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMSEC, COM.MICROSOFT.IMSEC, ORG.OPENOFFICE.IMSEC and _xlfn.ORG.OPENOFFICE.IMSEC are all #NAME? on every build, while the UNPREFIXED IMSEC(...) evaluates on every build. So LibreOffice implements IMSEC, and its OOXML import simply has no mapping for the _xlfn.IMSEC token Excel writes -- meaning a workbook saved by Excel that uses IMSEC arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is the same class batch D recorded for IMCOSH, IMCOT, IMCSC and IMCSCH. It is recorded as its own divergence class rather than as an ordinary unsupported-function result.