Whether or not to add the tags attributes to footprint in the furture, even to 3d shaper, so we can easily filter and find.
tags can be i18n organized, it benefit for all.
eg: add a tag “smt”, which can be display according to local set, like a desktop file.
tag = smt
tag[fr] = xxxx
tag[zh_CN]= yyyy
There already exists a keyword field that needs to be filled out. (According to the kicad library convention point 10.2.ii (or 4.10.iv for symbols). Off course there are still a lot of footprints that violate this rule.)
Also footprints have an attribute field for tht/smt/virtual. (part of the footprint properties dialog in the footprint editor) This attribute field is used to decide which footprints should be included in assembly files for pick and place machines. This is why they are called normal, normal+insert and virtual. (More details about this in the tooltip of this field.)
In the development version there already exists a user defined filter in cvpcb. (A filter where you can enter your search parameters into a text field and filter by that.)
If this is not enough could you give a better worded example of what benefits one gets with this tag field over a simple keyword field?
Also just a heads up: This forum is mostly used by users to help other users with the current software implementation. Only a handful of developers regularly visit this forum.
I’m not yet sure if your suggestion needs new features in kicad itself or if it would be enough to adapt the library convention. (I do not yet fully understand your suggestion.)
If the former applies you need to submit a wishlist bug at the bugtracker. Read the how to commit a bug first and also remember to check if a similar request has already been submitted. (Not everything of the how to applies to wishlist bugs!)
And now the bad part: There is a very small chance a feature is implemented if no developer is interested in it. This means you either need to implement it yourself or you need to get the attention of a developer. The later is best done by giving a good explanation of your feature request where you show what exactly the benefits are compared to what is already implemented.
If changing the klc would be enough simply create an issue over at the github page for the kicad library. But again: You need to convince the library maintainers that your suggestion is worth the effort.
Tl Dr: This forum might be the wrong place if you want to get direct developer attention. It might be a good place to get feedback from other users about your proposal. Either way you need to flesh out your suggestion such that others understand the benefits of your proposal.
We might want to start a locked thread in the meta category with the content of your last part and just link to that @Rene_Poschl .
Would save time 
I don’t think my post will affect the developers. I’m just here to make a point of view, perhaps the forum has a heavyweight who can agree with this, and then to communicate with developers.
Again: you might want to give a bit more details about your suggestion.
Flesh it out a bit. Make the usecase that benefits from it clear. (It might even be necessary to indicate your intention in the title of this thread.)
Currently i only see an implementation approach not a usecase description. (The later should always be clear first.)
If i understand your suggestion correctly it would require changes to the footprint file format (currently there are no indexable fields like your tag[abc] xyz suggestion.)
So there needs to be a major benefit that can not be achieved with the current system.
In other words: What shortcoming of kicad would your suggested file format change solve?