Mamma mia. Lo hai fatto sembrare complicato. 
In apparenza, applichi il tag fixed ai bug che sono stati risolti e completed alle richieste di funzionalità che sono state implementate. [1] Fa parte del processo di chiusura degli argomenti (e di aggiornamento delle parti interessate con le informazioni rilevanti). Sono stati inizialmente implementati per fornire un’indicazione visiva del fatto che ‘era successo qualcosa di buono’ rispetto al simbolo di lucchetto di un argomento chiuso. Quando questi tag vengono applicati in modo coerente, si ottiene un bel effetto a onde verdi quando si scorre l’elenco degli argomenti nelle rispettive categorie.
(E delivered era un tag separato ma simile, non controllato dal team, quindi poteva essere utilizzato in Marketplace)
Per Risolto, ci sono diverse categorie in cui è attivo, non solo la categoria generica Support. Praticamente tutte le categorie in cui la maggior parte degli argomenti saranno domande che possono ottenere una soluzione. Support, #installation, Development, #data-reporting, Support > SSO
Idealmente, la migliore pratica è che l’autore originale contrassegni la soluzione, ma sappiamo che a volte non succede (per una varietà di motivi), quindi spesso scorro indietro gli elenchi degli argomenti e ne pulisco alcuni pendenti dopo un paio di settimane (una volta che sono stati considerati ‘abbandonati’).
Per quel che vale, l’argomento Customization > Theme component per quello è Reader Mode, quindi in realtà quell’argomento feedback che hai linkato non dovrebbe essere in Customization > Theme component (poiché non è un argomento relativo a un componente tema). Dovrebbe probabilmente essere in Contribute > Feature o Contribute > UX, poiché penso che sia lì che questi argomenti hanno trovato casa ora che ce ne sono di più.
(Penso che fosse in Contribute > Site feedback poiché era un esperimento qui su meta)
e con Contribute > UX che rappresenta una via di mezzo tra i due, si può usare l’uno o l’altro a seconda della ‘tipologia’ dell’argomento specifico ↩︎