Well, here I am finally getting back to this.
In my previous post on resources, I glossed over one issue. Not all managed resources are exactly what they seem. Specifically at the metadata/compiler level, there is a table that simply points to the resource and gives it a name. This is very similar to how Win32 native resources work. A lot of managed code assumes that data stored there is a .resources file. There is actually a magic cookie value that is at the very beginning of the header for .resources files, but that's not exactly a guarantee that what follows really is a .resources file. That is why the compiler and ALink allow you to embed anything you want as a resource. Likewise Assembly.GetManifestResourceStream, returns just a stream. You have to know what data is in the stream.
As a side note, given this architecture, it seems like the metadata for 'managed' resources adds no value over the existing native Win32 resource format. So it seems like another case of NIH.
Way back before we actually had a good idea of what an assembly was (and before we had any tools that created them) the frameworks team just used raw .resources files sitting on the disk in the application directory. When they moved over to real assemblies, they decided to keep the same naming scheme. This led the compiler team (well basically just me) to come up with the novel idea of using the resource's filename as the default name for the resource. That way they didn't have to type the filename twice.
The problem here is that we weren't thinking about the big picture and how this would look to an end user who hadn't seen the intermediate steps. As a convention most people name their source files according to the class inside it. Thus it would make sense to name a .resource file after the resources inside it, but that doesn't mean we should default it. In fact if I were to do it all over again I would make 2 big changes:
I still think it would be possible to have managed resource embedded into the .rsrc section, but since they store things in different formats (like icons) it wouldn't help much.
Basically given the fact that I wanted resource names to be explicit, thats the main reason I pushed for not allowing wildcards. There was also the confusion about whether wildcards should be applied recursively. So I guess the end result was that nobody foresaw a huge customer demand, and the few people that cared (like me) seemed moderately opposed.