Unfortunately, your problems with Google Drive are symptomatic of a deeper set of problems. Changing some settings or switching to other tools or just using Drive differently might create a different set of symptoms, but it isn't going to resolve the core issues.
(Buckle up, this might take a while. The TL'DR version is: You should to have and implement a records retention and disposition plan, as well as a records access plan.)
So, what I take to be your "core" problems:
1) If users are freaking out, it is because the system they are using behaves in an unexpected way. Before you can solve the problems, you need to reset the users' expectations in a way that will allow you to implement solutions. Otherwise, your changes just make the system yet more capricious and unpredictable.
2) If you are relying on a loose set of "a few simple IT rules," you're probably DOA. Competent people make mistakes, and often times their mistakes are more. . . interesting. Competent people can also disagree about the best solution to a problem well after "best" has metamorphosed into "most intuitive." Where you can be flexible, be flexible; where flexibility leads to systemic problems, become rigid. There is no way to figure this out a priori.
The first step is to make sure users have a good idea where a certain kind of record will be. The second step is to make sure users know when a certain kind of record has outlived its usefulness and will therefore die. This is called a records retention and disposition policy (or "guidelines" for the bureaucratically squeamish—your corporate culture and legal needs will determine how "squishy" the records plan can be). A clear plan prevents (reasonable) freakouts, and gives you some wiggle room to start solving your problems.
Personally, I would start with as simple a records schema as you think will pass muster and then when users complain that a node of that schema has become unwieldy you can create subdivisions. If you have time to do a quick review of the research on menu tree design, this will be a huge help to your schema design and revisions.
(ASIDE: Any schema you devise will be somewhat arbitrary. What's intuitive to the goose is not necessarily intuitive to the gander. This is why Drive and similar tools allow users to "symlink" read-only folders into their own folder structure. Using CTRL+click to select multiple locations in Drive's "Move To" panel is incredibly helpful in this regard.)
Now that everyone knows what you're aiming for, you can select and implement tools that reinforce the plan. In your case, it sounds like "LegacyDrive" needs to be a read-only band-aid that holds old data while you migrate all of it into a current data structure. (That is, unless your retention plan calls for 'LegacyLegacyDrive's ad infinitum.) LegacyDrive, and perhaps other drives, will be read-only to avoid simple "Oh my. . ." scenarios, leaving you more time to deal with complex "Oh $#!T. . ." scenarios.
You can use Google Groups to better manage complex access rights (the link refers to Gmail, but the solution proposed there works for Google Drive as well). Google Drive folders generally inherit sharing rights from their parent folder, but you can change the rights for any child folder in any way you like. With a bit of practice and testing, you can create very sophisticated and granular role-based access schemas in Drive (via Groups).
If your corporate culture is such that users are accustomed to deep collaboration (and hallelujah for that), you might include an "open sandbox" folder inside every "closed" folder. The "owner" for the "official" folder can move files into the official folder or make changes there based on discussion in the sandbox. This approach is modeled on how open source software often has a "master branch" with a "maintainer" controlling access to the official build while still providing other areas and opportunities for completely open collaboration. YMMV; make local access and schema decisions as needed.
One other thing to keep in mind: There will be some things that Drive cannot do on its own without a lot of programming work. Sometimes it is easier to act on the files that have been synced to a computer, and to let Drive sync those changes back to the cloud storage. You may, however, need to restart the Google Drive application to get all those changes into the cloud. Drive's "on start" methods for identifying file changes is more thorough than its live methods.
If I've missed anything, well, that's why this answer is a community wiki. Please alter as needed!
Google Drive does not offer the option to search for other users' public documents (see here).
However, it is possible for users to find these documents via Google Search using a filter. In order to search exclusively for public Google documents, a user would have to search using the following:
site:docs.google.com/document/d [keyword]
To create a tool that would allow users to search for these documents, you might consider simply creating an HTML form that submits to google with the site:docs.google.com/document/d prepended.
Here's a quick demo of that using AngularJS:
https://github.com/cweems/Google-Docs-Search/tree/cc00038e67d6d3ff15ae19a271f0bfec99437b41
Navigate to the 'app' folder and then open index.html in your browser. Enter keywords into the text box and click submit: it will return a list of results that are only Google Docs.
Best Answer
If you set as project policy that all project files should be owned by curriculum@myDomain.edu then search for
This will return all the files that are not owned by the specified email address. Bear in mind that there are several other search operators that you could use to build your query and that now it's possible to limit the search to a specific folder by using the search within a folder search feature.
References