Thanks a lot everyone for your feedback! It helps a lot! 
I’ve tried to reply to most of the messages and write some conclusions at the end, let me know what you think about them when you find the time!
I personally think it can be very useful, but I also understand that this truly depends on the style of knowledge organization everyone has. Because of this diversity of styles, it’s important that XWiki supports as many of them.
I’m fully aware that the search dropdown doesn’t provide suggestions. I’ve written it here concisely, but there is the plan in the future to tackle the revamp of the dropdown and to include suggestions there. The structure of the dropdown would be changed so it won’t be confusing to users.
I agree completely it would need to be opt-in & it wouldn’t be good for public wikis to suggest configured tags unless those websites know their average user’s interests very well or/and they want to conduct traffic to a certain category of knowledge.
This will be debated more in the discussion about the search revamp, but even for xwiki.com I can see suggesting tags in search very useful. Again, a topic for another time, let’s focus on the colored tags in the footer of the page for now 
Yep, aware of this. It’s in my plan to look at that page too. 
From my own perspective, we should first fix the look and experience for the first things the user interacts with when discovering the product. This is at least my thought process in setting revamp priorities, but I’m completely open to suggestions, especially every time we set the monthly roadmap and I propose what I’d like to work on that month.
Tags are clearly in this category and colored tags are something many software have in some form or another (either as colored tags or colored dropdowns). It’s also something we can improve so we have an advantage in a specific feature area. For example, many Notion users requested tag support on pages, yet they still do not have it (they have select/multi-select in databases and users can use databases to create a workaround, but it’s not ideal).
I think this may be the better way to go, keeping in mind all of the feedback.
This seemed to me slightly more complicated to implement on the backend (and, thus, implying more hours spent on this from a dev), because each tag would have to have a color (actually a CSS class) corresponding to it. Maybe this is easy to do or we have most of what we need to implement it easily (would appreciate if someone could let me know about this).
Also, the tag addition UI would need to be custom fully as it would need to offer the posssibility to add color to any tag (not just select from a list of 4 predefined tags) and I tried searching for an open-source UI that could implement this, but haven’t been successful yet. Esentially, we’d jump directly to a more generalized full requirements version so it would imply a bit more effort form the start.
An idea for this tag addition UI would be the following (which i will explore in a seperate proposal after we decide what to do about colored tags):
User opens modal for adding tags
User defined a tag
User defined multiple tags
Conclusions based on feedback
This proposal is changing from having an initialy small, static list of colored tags to creating the possibility for a user to create a tag with a certain color attached to it. That color will be used everywhere that specific tag appears.
A possible version for the tag additon UI is described in the previous paragraphs. That UI is a custom one and we might not find one that is already existent, open-source and supported.
Of course, we could use a tag input UI (example) and add extra functionality to it, but the experience of a tag input UI without colors is entirely different than what we need, tbh.
