Notwithstanding @gabix’ remark, I’ll try to answer.
User expectations about document composition have become very high with time. User now requires very complex things from his suite.
Speaking only for Writer I know best, we now want not only visual variations in text (font face, size, weight, color) but also structural organisation (paragraph rendering, headings with auto numbering, lists, cross-references – including header/footer capturing excerpts from main text flow --, etc.).
There are only two ways to handle this from user point of view:
The markup is hidden under a plethora of pre-cooked menu items or buttons. This is the WYSIWYG approach of common office suites.
The first approach offers end user full control at the expense of a tedious programming which explains why specific-domain layers (APIs) have been developed to ease paper writing in various situations.
The second approach tries to leverage access to document writing by offering so-called “intuitive” use after developers have chosen which features they shortcut through menu items and buttons. It becomes “intuitive” after you’ve fully understood the basic principles they’ve applied. Unfortunately, these primitives are rarely made clearly explicit.
To make matters more complicated, user expectations increase with the success of office suites and features are added to address new requirements. The main source of trouble is this dynamic nature of specifications. Some new features must be added anyway to keep abreast in competition versus other suites, despite the number of pending bugs. Due to the limited number of developers (in FOSS as well as in closed/commercial apps), there is a trade-off between curing known bugs and adding awaited features.
Also, office suites are used by millions (billion?) people with diverging needs. What is surprising is suites succeed in coping with such contradictory needs and workflows. Of course, this is not optimal for everyone but the result is impressive.
I personally find the case of LO is acceptable. Of course, I’d prefer it to be bug-free, but compared to M$ Office, I can file bugs and get feedback about them. There is some reactivity (of course, I’d prefer a shorter time-frame but not being a contributor I can’t complain for a free app solving 99% of my needs), reactivity completely lacking with M$ Office (take it as is or don’t take it).
To fully appreciate the “swarm of issues”, I’d like to read the code (or some part of it) but the entrance fee is rather high. I have not found any architecture document which would help finding my way through this huge code base. I’m afraid the synthesis document I dream of doesn’t exist. Its maintenance cost would anyway be tremendously high.
Another cause of problems is standardization. Many bugs or feature requests are discarded with “ODF incompatibility” reason. Even questions here are answered with this argument. I fully understand the need to have a reference frame for developers and portability of documents. This reference must also be stable enough so that development can reach mature state but it must not create a locking situation.
This is where some issues find their origin: the reference must be carved into a pre-existing base with perhaps contradictory primitives. All suites are certainly affected by the phenomenon.
I’m not convinced that switching to another suite will confront me to less issues. They’ll be different and I’ll have to learn new strategies to live with. I’ll also have to re-learn the underlying principles to benefit from the new suite. And, in the end, there will appear other issues.
I just hope developers have enough time to fix bugs and also add really value-added features leaving aside cosmetic time-consuming gadgets. I admit I don’t know how development is regulated.