Currently, cross references are implemented as fields. You set a phrase or heading as a source, then you use Insert Reference in the appropriate passage.
The weakness of this technique is that you have to add suitable words around the inserted reference, such as "For more information, see . . .," or "page" or "chapter." It's a clumsy implementation, and no better for the fact that other major word processors take a similar approach.
Instead of treating cross references as fields, LibreOffice would be better off treating them as simple versions of indexes and tables. The strength of Writer's indexes and tables is that they consist of building blocks that can be pre-arranged so that an entire entry can be created with a couple of keystrokes.
Some letter combinations, such as "ff" or "fl" make for awkward spacing that spoils the look of the page. For this reason, some typefaces include special characters called ligatures to use in place of these letter combinations.
When a typeface includes ligatures, you can add one as a special character. But it would be far easier if paragraph and character styles had the option to substitute ligatures automatically whenever possible. Perhaps all that would be needed is a table of substitutions, since the Unicode for the most common ligatures is usually consistent.
Outline numbering in Writer is a mess. To start with, Writer has two tools for creating numbered outlines: Tools -> Outline Numbering, and the Outline Numbering tab in the Page styles dialog. The trouble is, neither has any connection with the other. Of the two, Tools -> Outline Numbering is probably the most useful, especially once you notice that you can substitute any paragraph style for the default Heading styles.
However, Writer lacks an outline view which is both readable and displays all paragraphs in a hierarchical tree whose levels can be expanded or collapsed at a click. The Navigator has some of these capabilities, but it is too small to be useful for anything except a short document—which probably doesn't need an outline view.
The best alternative is to do an outline in Impress, taking advantage of the naturally hierarchical structure of slide shows, then copy it over to Writer when you are finished structuring and ready to write. However, this is a clumsy workaround compared to a built-in outline view in Writer.
In the Tools menu, Writer includes a Bibliographical Database. Unfortunately, it is rarely used because of several basic problems.
First, the database is used for all documents, not a single one. Once, this choice might have saved memory, but now it means that either the database quickly becomes unwieldy, or else users must spend time deleting references that are no longer needed. In fact, they might want to start by deleting the sample references.
Second, the database is poorly designed. Unless you take the time to experiment, you might not realize that the Identifier column corresponds to the Short Name field. Moreover, to edit a cell in the Identifier column, you have to use the Identifier field. Try editing the contents of the cell, and the next time you open the database, you'll find that your changes weren't saved. You might even conclude—like countless others before—that the database is broken.
But by far the most serious problem is that the examples of the Short Name or Identifier are misleading. If you have created a bibliographical entry using Insert -> Index and Tables -> Bibliographical Entry, you will know that the Short Name is the reference that appears in the document—under most systems of citation, the last name of the writer. But the included samples are abbreviations that have no function whatsoever. Simply including realistic Short Names in the samples would be an important step in making the database useful.
Ideally, the samples would also include sample entries for different citation styles—at the very least, the Chicago, APA and MLA styles. Or perhaps, when adding a bibliographical database to a file, users might be given a choice of which style it should be in.
These are only the most overdue improvements for Writer. LibreOffice as a whole has a list of long-delayed improvements all of its own.
For instance, why does LibreOffice not ship with its own set of document and slide templates? Many distributors include their own, but far from all. Beginners would benefit from templates as they learn how LibreOffice does things.
Another question worth exploring is which apps are required in a modern office suite. Like Calligra Suite, LibreOffice could use a full flow chart tool, not just the rudimentary shapes among the drawing tools. Perhaps, too, the modern office suite could benefit from tools unthought of in the long-ago days when StarOffice owned the code, such as a mental mapping tool.
Most of all, though, LibreOffice needs to give its interface a higher priority. While some pieces of the interface have been improved, many remain formidably obscure and unfriendly by modern standards, including Autotext, Fields, and the Mail Merge Wizard. While LibreOffice's functionality is usually a match for rival proprietary office suites, its drab appearance remains stranded somewhere in the nineties.
The Document Foundation that oversees LibreOffice has done far more than anyone expected when it was founded. However, much remains to be done—no doubt with too few codes and too little funds. Writer, as LibreOffice's most widely used tool, remains a logical place to focus. Perhaps when LibreOffice moves beyond its next major release, they can at last address at least a few of the longstanding deficiencies.