There are so many aspects to this, I can't even think of where to begin.
I don't think we want to impose a system where the user doesn't have full control over their local content. Of course, this means that they also have the ability to royally screw things up.
I don't think UIDs are going to do us any benefits unless we plan to do some sort of centralized content management system - and I don't see that happening. Without the central control, there really isn't anything to enforce it, so why bother trying? By and large, I think most members of the train sim community want to be respectful (although it's certainly not always the case). So in terms of per-user organization, I think we need to perhaps adopt a convention, but not enforce anything.
As much as I like databases, i don't a think full-blown RDBMS belongs on a user machine for just one program. So we're left with files. We should probably avoid having to index every file to look for keys that might be referenced from inside other files since this leads to scalability issues, so that leaves us with linking the files directly.
In terms of file references, I think we need to keep it as flexible as possible. I propose that file links should all support absolute, relative, and aliased (both named and a default) paths. I don't think absolute paths (i.e. 'C:\My Folder\Something\thefile.abc') will be used except maybe in testing, but I don't see why we should specifically exclude them. Relative paths ('textures\mytexture.dds' or '..\..\common\tree.cfg') will be useful for child content, with the parent directory pathing probably having some occasional valid reason for use. Aliased paths will be a big benefit in flexibility of configuration. As I brought up
here, we could use the tilde (~) as a special character to denote an alias. ~\ would be the default (whatever we decide that should be) and then ~[name]\ would resolve to whatever the [name] path was set to. I don't like the concept of asking for a file, and then it looks in one place and then another if it doesn't find it in the first place, and I don't think it's necessary if we aren't planning on having a massive pile of stuff in a global folder.
This would allow people to organize their content however they see fit, but still allow for commonality between users using aliasing. We could offer a set of out-of-the box aliases pointing to folders intended for certain types of content (track, cabviews, sounds, etc.) with the hopes that people will latch on to that. It would be possible to create a sort of package installer that could copy files into the various aliased locations to aid in setup.
For rolling stock, we could have a configurable lists of locations using paths as designated above that will be included when putting together consists. This would probably work for shapes too during route construction (although I haven't looked at the next gen route editor doc to see what direction that's going).
Regarding keeping related content together versus spreading it around, so long as people are going to latch on to other peoples content, I would advocate splitting it up by type rather than by project. What I've proposed above won't preclude either method, but I think we should be encouraging reuse, and having to reference a cabview off in some folder that was originally specific to one locomotive is not the cleanest solution. As long as the content creators play nice and pick unique references, then you could have your BZZ folder underneath several locations that you could park your content in depending upon type.