Just a couple comments on your message:
- the ability to collect connected metadata is, as you point out, a limitation of SP 2007, and has been added in SP 2010.
- metadata are essential for cross-referencing content, and this is especially useful in matrix organizations. It is true that you won’t see much benefit in pure hierarchical organizations. Also, I often see situations where a document is associated to multiple projects, and in this case folders just don’t work. So I completely disagree with your last statement.
- “it can be done in code” and “it needs to be done by a programmer” are two different things, and one of the roles of blogs like Mark’s and mine is to make code accessible to non-programmers (agree, easier said than done).

Now the good news. The easy way to handle this is to have each project be its own SharePoint site. But, you still need your project list in order to maintain the project-based metadata. To that end, I wrote a tool called List Item Workspaces that allows regular users to create SharePoint workspace sites based on any list item, similar to the way that document and meeting workspaces behave.

With the List Item Workspaces tool, you can create your central project list with the metadata you need to track. When you add a new project, the List Item Workspaces tool will automatically create a team site for the project and maintain the linkage between the list item and the team site. All project documents, tasks, links, contact info, and other items go into the project site. This way users always know which project they are in and do not have to constantly worry about setting filters on the documents, tasks, contact info and other list items that they work with in SharePoint. Best of all, the Office client applications will show users only the content related to the current project. You can even use Mark’s suggestion of using the CQWP for aggregating data across multiple projects.

We use the List Item Workspaces tool on our own portal for managing projects and much more. You can see the tool and download it free from:

http://www.blackbladeinc.com/en-us/products/liworkspaces

Hope this helps.
-Eugene

This site column can now be used anywhere throughout the site collection. On your project document library, add the site column “Project Name” and every document will have a project name associated with it. When the document library is displayed, clicking on any name in the Project Name column will drill down to the project name item, giving all the information stored about that project.

Another BIG advantage of doing it this way is that now you can use a Content Query Web Part to roll up all information about a project, since CQWP searches against site column values.

Hope that helps,
Mark

I have, however, been told by a dozen people that “all of what you want can be done in code.” That’s certainly true, but we don’t have programmers available, nor are we prepared to invest all the time needed to design, then maintain, a custom application.

Folder trees may be archaic and inelegant, but they’re the only approach that allows Sharepoint to be used as a reliable structure for storing and sharing documents that are associated with a specific business construct, such as department, project, etc.

Email Subject, Folder Name, Email Sender
Group By Email Subject, Folder Name

One additional tidbit; SharePoint views can traverse items in folders… so it allows for the best of both worlds, items stored in folders can be presented using the power and flexibility of filtered and/or grouped views by activating the “Show all items without folders” in the view design.

Cheers,
Robin

One point I don’t agree with, though: I’d say that folders do grouping, and this is actually their main function. The difference with metadata is that folder grouping is exclusive – an item cannot be referenced under two different folders.

I’m excited to learn more about SP2010’s ability to more easily tag multiple items with metadata. That will help with our end user adoption.