If a properties has more than one elements, such as in my case;
NOTE1.md
area:
NOTE2.md
area:
When using Group By: “area” sorting, they are listed in two different groups;
Finance
Finance Business
A much better way would it be;
Finance
Business
No useful workaround, other than not having more than one element in the “area” properties.
Totally agree. According to a team member in this post: Bases grouping (by property of list type) - Help - Obsidian Forum, this is not a bug, but the intended behavior.
There may be use cases for the current behavior, but I cannot think of one. On the other hand, there are many instances where I need the proposed behavior. If I am looking for movies of the Comedy genre, I want to look in the Comedy group regardless of whether the movie was also a Romance.
The only workaround is to use dataview which can split a list of values into separate groups. But then you lose the speed and editability of bases.
seconding this request, as I’m making a Cookbook base and I want a recipe to show up in main dishes AND also in sides, not in a new group called main sides
Same here, I’m trying to group music by author, but wher there are multiple ones for the same song (for example A and B), it creates a new group that lists the songs of “A B” rather than duplicating the entry and letting it show up in group A and in group B indipendently.
I feel like this change may allow list to be helpful in classification of stuff, while handling them basically as a string that concatenates all the elements of the array is not that useful imo, I’d rather use a string from the beginning at that point.
I agree. For me this feature request was the expected default behaviour. If I have a property Categories with Fiction and Drama, I don’t expect to get a group Fiction Drama and even Drama Fiction if I accidentaly mess up the order. I expect the movie or book to be listed in each of both categories (groups). Later I have other means to show me all books with both categories.
Well, this is only an example. Of course tags could be helpful for this kind of categories… 
Thanks for sending in this feature request. I think it is an important one to make bases even better.
Totally agree!
Perhaps, when the property selected for Group By is a list, the interface could present a toggle switch.
Switch one way, and the current behavior is seen: Each group corresponds to one state of the list that is the Group By property. Each note thus appears in at most one group.
Switch the other way, and the behavior here is displayed. For each list item that is found in at least one note’s Group By property, a corresponding group is displayed. A note can thus appear in multiple groups.
That would at least make this proposal feasible interface-wise, I think.
On reflection, I think is an even better interface idea than the one I suggested previously:
The list of all the properties the user can Group By gets populated with two entries instead of one for each property of type List.
The first entry is the unadorned property name, and results in the current behavior.
The second entry is suffixed with “by items”, and produces the proposed new behavior.
I agree this would be a significant improvement to the usefulness of Bases. Thanks for developing in the first place 
A third option is having nested groups:
Finance
NOTE1.md
Business
I’ll just throw a +1 to this feature request. My use case is for grouping books I’ve read by date. I re-read books periodically so I track the “readDates” as a list. I’d like to group books by year read and for the same book to appear in multiple years if I read it more than once.
Partly this is to track my actual reading behavior but also to get accurate page counts for each year.
+1, there are many use cases where this would be the preferable way for grouping to work
Was just about to create this exact request.
If we want to see all list items that apply (the way grouping works now) we can just include the list field in a column. There is no need to “group” by it.
Example:
When I see that “When Harry Met Sally” is listed under the group “Comedy”, I can just look at my ‘genre’ column next to the file.name to see that it is also “Romance”. I don’t need groupings that display ‘all’ the genres it belongs to; I need groupings that display ‘each’ genre it belongs to.
Besides, if we wanted to group by all items in the list we could just leave the field as string, which would group by the entire string rather than it’s comma-delimited parts.