Ach. Das klang kompliziert. 
Oberflächlich betrachtet, setzt man das Tag fixed auf Fehler, die behoben wurden, und completed auf Feature-Anfragen, die implementiert wurden. [1] Es ist Teil des Prozesses, die Themen abzuschließen (und interessierte Parteien mit relevanten Informationen auf dem Laufenden zu halten). Sie wurden ursprünglich eingeführt, um eine visuelle Anzeige dafür zu geben, dass „etwas Gutes passiert ist“, im Gegensatz zum Schlosssymbol eines geschlossenen Themas. Wenn diese Tags konsistent angewendet werden, erhält man eine schöne grüne Welle, wenn man durch die Themenlisten ihrer Kategorie scrollt.
(Und delivered war ein separates, aber ähnliches Tag, das nicht teamkontrolliert war, sodass es in Marketplace verwendet werden konnte)
Für „Gelöst“ gibt es ziemlich viele Kategorien, in denen es aktiv ist, nicht nur die allgemeine Kategorie Support. So ziemlich jede Kategorie, in der die Mehrheit der Themen Fragen sind, die eine Lösung erhalten können. Support, Installation, Dev, Data & reporting, SSO
Idealerweise ist die beste Vorgehensweise, dass der OP die Lösung markiert, aber wir wissen, dass dies aus verschiedenen Gründen manchmal nicht geschieht. Daher scrolle ich oft nach ein paar Wochen durch die Themenlisten und bereinige einige ausstehende Themen (sobald sie als „verlassen“ gelten).
FWIW Das Theme component Thema dafür ist Reader Mode, also sollte das feedback Thema, das du verlinkt hast, eigentlich nicht in Theme component sein (da es kein Theme-Component-Thema ist). Es sollte wahrscheinlich in Feature oder UX sein, da ich denke, dass diese jetzt dort leben, wo mehr von ihnen existieren.
(Ich glaube, es war in Site feedback, da es hier auf Meta ein Experiment war)