Yes, good point. Although the example furthest to the right in your image is a bit artificial, this doesn’t allow much flexibility for theming. It would probably be better to only use the blue highlight for the headers and keep the regular subpanel header text color when the panel matches the search.
A few people have said this, so it must be worth looking into. I would like to keep it easy to interact with buttons surrounding search matches though, and dimming them to 25% might make that quite hard. That’s my only hesitance.
We’ll have to decide which state is more important to convey during a search. If a button is inactive, the user searches for it, interacts with it, and it doesn’t do anything, that would be a failure of the UI. Maybe this is where the 25% state could be useful. Something like this:
25%: Inactive and no search match
50%: Inactive and search match
100%: Active and search match
What you suggest sounds much more complicated than I would hope for. In my opinion we should not be designing around situations where the label doesn’t match the property at all like in your example. While testing I have found a few situations where the property UI name doesn’t match at what it’s being used for in the interface. We should fix those first before changing the search.
Also, searching both the label name and the property UI name is sort of the point. It allows for a highly specific search (“I remember the label for this property, where was it?”), but also a more general “How do I accomplish this?” search, where the UI names might provide more of the necessary context than the labels.
I like the idea of simultaneous search for multiple properties though, that could be cool.