The complication here is the relationship between folders, filters and views in the console UI isn't well-explained, either in the console UI itself or the Implementation Guide (things are a little better for the filter query language, but even that has some core concepts in it that aren't really explained properly anywhere).
Anyway, what filters are designed to do is generate lists of machines. Each sub-clause in a filter query language actually looks independently (without reference to other sub-clauses) in the collected WMI data for every machine there is and returns a set containing every machine that matches. This process is run for every sub-clause in the filter, then the conjunctions between the sub-clauses (AND, OR etc) are processed to merge these separate lists of matching machine IDs together in various ways.
[ The strange "grouping" operators in filter queries change the above a little by adding extra tags to the lists of machines representing which specific instance (SQL row, more or less, since WMI is an object-relational mapping) matched in each sub-clause and considers those tags when ORing and ANDing. ]
So the result of a filter is always a list of machines which match the filter conditions, which can also be further conditioned by restricting it to a source folder.
So, filters result in list of machines. The "grouping" operators in filters are the only thing that drill into the level of an "instance" but that information is discarded by the time a filter has done its job, and only a list of machines remains.
All this query processing isn't done in the console UI, by the way; it's done inside the NGSERVER.EXE service executable, because what filters were really created to do is dynamic folders. Since dynamic folders are lists of machines and the NGSERVER.EXE code is supposed to contain all the logic for running tasks rather than the UI, the notion that a filter results in a set of machines is really physically embedded into the structure of GSS.
My understanding (which is less certain than I normally am about things in GSS, because I didn't develop or maintain any of the UI code for the GSS console) is that views, in contrast, are purely a console UI concept. They just choose property values from WMI classes to list in a big output table, and that's all they do.
So with these, we can conjecture how reports work; they run a filter, which by design does nothing but produce a list of machines (just as a folder represents a list of all the machines in it). Then that list is used to select which items are sucked into the view, and the views then retrieve for each machine every row of data matching the items set to be included.
So, the problem here is the implicit behind-the-scenes handling of multiple instances; the filters do have a very crude mechanism for representing instances if you use the grouping operators, but the filter query language doesn't return this information to condition the set of things shown by the view, and views are a separate concept that just dumps every instance without regard to anything else.
So basically, if my understanding is correct, the report system just isn't quite powerful enough to do what is necessary here.
To work around this you'll probably have to bypass the console UI and query the underlying WMI data store in the console's database directly, which is a little awkward to do unless you're au fait with VBScript and ADO or similar techniques.
There's some example code at http://code.google.com/p/gss-scripts/source/browse/trunk/scripts/clientname.wsf#302 which shows some of this to query the console database in script and figure out the console's idea of what machines are named from their database IDs. That's one part of writing your own WMI report by hand.
The second part would be to dig into the WMIData table within the console database; that has all the raw WMI data, organized by ID codes for the WMI classes and property names (which are in other tables whose names I forget but are probably something like WMIProperty and WMIClass).
There you need to write a query (or several, since it might be easier to to run over the WMIData table in several passes) on the WMIData table to get a set of WMI instance IDs to match C: drives, and then get the property value that represents the VolumeName, along with the corresponding machine ID code. Then the code from the sample above can get the name of a machine corresponding to the machine ID code, and you can print out a row to an output file or something.
Can't say that it sounds like very much fun, but I think that's how things work in the GSS console at present so getting down to the metal with the WMIData table via scripting might be your only option.