Created attachment 125710 [details]
Same document with re-added 0 saved on master

Created attachment 125711 [details]
Diff of content.xml, except all the style changes

 61c39eae570d6d6040b65bfe93127b30e6080cc8 Display blank cell instead of zero in matrix cells with blank text result

actually breaks the import.

Couldn't really prove it, as I wasn't able to build 4.0 to do a bisecting, but reading the commit message makes it quite clear.

And since in the content.xml diff "calcext:value-type" is set to "float" for current saved document from Calc on master and the current code runs into 

void ScXMLTableRowCellContext::EndElement()
{
    HasSpecialCaseFormulaText();
    if( ... )
    {
        CellType = util::NumberFormat::TEXT;

in debugrun for the original document, breaking the import.

Commenting the "CellType = util::NumberFormat::TEXT;" line fixes the import, but is definitly wrong. I still try to understand, what the code is expected to do.

There is this comment, which I think is exactly my use case

// If a matrix formula has a matrix reference cell that is intended to have
// a blank text result, the matrix reference cell is actually saved(export)
// as a float cell with 0 as the value and empty <text:p/>.
// Import works around this by setting these cells as text cells so that
// the blank text is used for display instead of the number 0.

Switch "commit message" in previous comment with code, especially the quoted code comment.

Ok - probably commenting

 CellType = util::NumberFormat::TEXT;

is actually correct … in a way.

I don't know, why we ever want to forcefully change the cell type.

Probably we should just change the type, if the current cell type is undefined, so we get

if (util::NumberFormat::UNDEFINED == nCellType)
    CellType = util::NumberFormat::TEXT;

That code survives: sc.check, sc.slowcheck and sc.subsequentcheck

And it fixes my bug.

To create the initial document:

1. Use OOo 3.2.1
2. Put 0 in cell A1
3. Change cell format to 'user-defined', value:
 [>0]Standard;[<0]"";""
 => The value 0 is hidden
4. Evaluate cell A1 via C1 by using 
 =IF(A1="";"is empty";"contains 0")
5. Save document.

Load in any LO >= 4.0.3

So my latest Gerrit patch @ https://gerrit.libreoffice.org/#/c/26435/ simply removes this line. At the end I still don't know the expected behaviour.

Commit 61c39eae570d6d6040b65bfe93127b30e6080cc8 introduced the overwriting cell type as a workaround.

// If a matrix formula has a matrix reference cell that is intended to have
// a blank text result, the matrix reference cell is actually saved(export)
// as a float cell with 0 as the value and empty <text:p/>.

This is the same in my document AKA 
 <table:table-cell office:value-type="float" office:value="0">
   ... annotation
   <text:p/>
  </table:table-cell>

And strangely this overwriting was just done exactly for this case, with the quoted comment in front of the code:

+    if( rStr.isEmpty() )
+    {
+        rnCellType = util::NumberFormat::TEXT;

The current code expands the overwriting to a broader range of cases (sc/source/filter/xml/xmlcelli.cxx:1511), and this might also be wrong. Actually my document works correctly _without_ any special handling of cell number type, just by resetting the text, and breaks _with_ the overwrite.

// Import works around this by setting these cells as text cells so that
// the blank text is used for display instead of the number 0.

This reads as we already fix the import problem with a workaround, and if the comment is correct, it's not needed any more, which is proved by my error case.

As bubli noticed, and I already forgot, there was also a commit for a unit test, which still seems to pass (I have to check, if the code is still there, to be sure).
 abdffd2e442356782ee6bd947936afc7fb9e4287 Add test case for matrix reference cells with blank text result

Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=21a3d78cf080dc4d86edab2a7378055a2d848bfe

tdf#100458 Don't forcefully change cell type

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

So this is fixed in master given the above commit, right ?