Complete system of "Tag" and "TagGroup"

Very interesting. Lately, I have been experimenting with how to categorize Blocks into Layers where some Layers would act as a Category of objects, other Layers as a level of detail, and different Layers would categorize my project in parts and design options. This led to the nested block structure scattered on different Layers - insanity…

I just watched your two videos on YouTube and your project is very interesting. Probably for some more sophisticated filtering methods visual approach as in Grasshopper is just easier to read, but nonetheless, the UI you created looks very useful.

That being said, Blocks are still important and you can’t turn off the visibility of objects that are inside Blocks. If I understand thing correctly, In order for this system to work you need to have somewhat flat structure of Blocks (so you turn off the visibility of the whole Block Instance) and you can’t have inside one Block two objects that would belong to different “categories” (having different tags). Objects inside Blocks can belong to different layers and you can turn off the whole layer, but that’s what I would want to overcome with Tags.

In short: you left Categories to be steered by Layers and shifted Design Options to be controlled by the Tags. Clever, but I wonder if the opposite would be a good idea: letting Tags control the Categories visibility and Layers control Desing Options.
If you use Blocks, elements inside have “pre-made” Key Values so they are automatically categorized. If you actively work on some design option, and you decide to use Tag values to group them, you need to remember to assign tags to every object from that option. If instead you will use layer to control the visibility of the design option, placing these objects on a given layer does that for you automatically.

If you want to have the ultimate flexibility you can of course use Tags for both Categories and Design Options. But here the Objects inside Blocks visibility problem arises.

@Japhy Do you know if something about it can change in Rhino? It looks like for this to work with more complicated Blocks there must be per Block Instance visibility override of every object inside the Block.