Bug 40590 was written against 3.4.3. When I tested the first fix that was "approved" it did not correct the problem. A subsequent additional change was made that did fix the problem. The secondary problem had something to do with needing to have a second pass to resolve forward reference names. In other words name "b" referenced name "c" and "c" has not been resolved yet. Where possible, changing the names such that all references to other names are reverse in collating sequence instead of forward avoids the problem. In other words, change name "b" to name "d" and the problem is avoided. The notes on 40590 should be helpful. I'm going back to 3.4.3. I cannot understand the poor quality control that exists within the LibreOffice development organization.
Created attachment 53387 [details] Simple sheet that demonstrates the bug This sheet demonstrates the bug.
Bug 40590 says "fixed in master", that's what it is. The fix was considered too invasive in a review to be cherry-picked to 3-4. *** This bug has been marked as a duplicate of bug 40590 ***
This bug has been marked as CLOSED DUPLICATE OF 40590 which in turn says RESOLVED FIXED. The definitions of those words is subject to interpretation. As it turns out, the fix will not be included until at least release 3.5.0. The bug was introduced in 3.4.3. 3.4.2 worked correctly. 3.4.3 created the problem. The fix is now stated as being too invasive to include in 3.4.4 or 3.4.5. Amazing. They broke it in 3.4.3 but the fix is "too invasive" to be implemented until 3.5.0 at the earliest. With this operating philosophy I don't believe that anyone should consider LibreOffice for use in a true production environment if your software maintenance policy embraces the concept of installing incremental fix releases. See bug 42745 for more.