Thanks, this sounds quite useful. Some additional points:

• We should also provide a way of listing all available tags, e.g. as a special line which is part of the -l output.
• I propose that we call the new keyword tags, which is more in keeping with how this concept is called in other places.

The keyword mentioned in the docs is just an example of a general entry. You may basically add any keyword to the design, even if boxes is not making use of it (as you did). I will try to reword the documentation to be clearer.

I agree. The whole idea stemed from the example you gave with "keyword", and I thought immediately it would help to sort better all designs. But tags is better, shorter and more to the point.
This is the kind of thing that is best to implement before the designs grow too much in number—usually it all happens in a flash: the tool suddenly reaches a tipping point and everyone is using/contributing to it. It only takes a good review in the right place.
I think it could be implemented like this:

• "-tags" and "-t" list all available tags
• "-t some_tag" lists all designs associated with that tag (thus, would not require "-l" at all)

Instead, "-l" could take further the name of designs, which makes it useful for filtering out by wildcards (eg: "-l round_" would show all designs starting with "round_", to narrow out the very long output)
Also, it would nice to have also some sorting by author/designer... Not a high priority though.
What I'm not sure about is wether the -tags option should just list the names of the designs (and their description) or show a full sample.
Maybe, designwise, it would be simpler to have all such switches ("-tags", "-l", "-author") by default show details and sample; and add another switch (eg: "-compact") to produce only basic design info.
This would provide a flexible approach, without commiting too much in a direction and closing doors in another. After all, we can't know yet what other keywords are to come (I expect more will come into need with actual usage).
Boxes is like cowsay/thing, lolcat, fortunes, figlet, ecc., tools that keep popping up again and again, that are implement and reimplement, ported and translated. A bit like Pac-Man, the unforgettable old-school arcade game, that no modern console game will ever outlast in fame!

By the way...
A good way to output tags list would be in alphabetical order, in the format:

animals (6) | framed (12) | rounded (2) | speechbubble (4) | square (1)

with each tag followed by the number of occurences.
Also, in prediction of "tag madness effect" (people overtagging, or tag-spamming), multi-tag filtering would also be a good idea to implement (with "and|or|not" suboptions), to further narrow down designs viewing. Eg:

boxes -t framed animals !speechbubble

would list only design containing "animals" and framed tags, but not those with a "speechbubble" tag (!) — or something along those lines.

Thank you for sharing these good ideas. I see what you mean, and largely agree. I also like the idea of giving the number of occurrences.
I would not be afraid of the "tag madness effect" so much, because tags would only get in there through pull requests, so the reviewer can make sure tags are consistent and meaningful.
So we should be able to keep the options simple, i.e. without boolean logic and without introducing options that only have meaning in the context of other options.

True, but this applies only the repository version. Being the license open and permissive, nothing prevents parallel distribution of of boxes, or modded config files, or even collections of single-file designs. So, "tag madness effect" might also apply in other cases:

• localization — someone transalte tags into another language (so he can take advantage of them, by understanding them.)
• collections merging — external boxes designs and/or config files found around the web are merged together.

Also, tag swtiches are not intended only for humans, but also for scipt-automation, ecc. Keep in mind that boxes, like FIGLet and cowsay, is often used in a toolchain for automated tasks like email signatures generation, random quotes, ecc. I've actually got to know about boxes from an ASCII Art website that offered good tutorials on how to setup such a toolchain for automating random signatures in emails.

So, in such cases, atomic tags filtering is a blessing because it would garantee that certain contents never get through the random selection.