There is one UX behaviour that bothers me. It’s the way grouping works with multi select data.
It “merges” multi selected fields (if more than one value is selected), and therefore creates a new value for grouping. I can imagine that from the design perspective, that might be a straightforward solution. From UX standpoint it might be not the user intent.
Imagine freelance developers capable of using different frameworks/languages. Let’s assume “Developer A” is fluent in both “python” and “ruby”.
I group them by “language”. In 9/10 scenarios I would be looking for a single language, in 1/10 I would be looking for a person that Person being both a python and ruby dev.
At this point, grouping by “language” would make every possible permutation of “languages” a single group. Person knowing “js” & “python” & “ruby”, would not be in the same group as a person that know “python” & “ruby”.
If I were to look for “python” devs I could not use a group by card view, since they would be all over the place, an UI hides the information about “multi select” used making it +1 or +2. I would love to see “DevA” in all the columns he should be (both, python and ruby in this example)
I get the logic behind the current state, but for my use cases it’s sub optimal. I believe ability to pick grouping behaviour (combine the multiselect, or split the multiselect) would be great.
A little image of the current behaviour 
