I'm not sure I like the idea of adding more URL information. If anything we want to reduce it. For the most part, google does not traverse databases of information often found after the "?" in a URL. If anything we'd implement a mod-rewrite strategy to clean up URLs and make them appear like the URLs in the atutor.ca forum, which have no "?" in them, thus they are indexed fully by google.

A course url could be constructed to include various ids as directory names in the example above, something like

www.example.com/atutor/12

www.example.com/atutor/12/content/175

We could also replace the course id (12) with a slug defined by and instructor, or admin, something like

www.example.com/atutor/my_course/content/175

where "my_course" is the slug defined by the instructor to represent the course.

On Sunday I've read some docs on mod_rewrite, and tried to implement the subj. I can't say it worked as it should, but some points can already be made.

1. About the URL construction.

If we use mod_rewrite, then there won't be basically any difference between specifying the course ID in the path part and in the query part. That's because the very first step that RewriteRule directive will take will be replacing e.g. "/course/12/index.php" with "/index.php?course=12". Right after this moment, the two suggested URL schemes would become indistinguishable.

2. About the compatibility.

Vegard is right about its highest priority, and it seems it could be got for a low cost.

ATutor uses relative paths to files stored in the file manager. That's why as long as <base href=...> uses permalinks, there should be no problems. The web server will adjust the paths to images just like it does for PHP files - which would result in extra "?course=" appended, but it will make no difference.
Or, we can even use additional RewriteCond to prevent that appendix from being added for any files except PHPs.

vitals.inc.php (or some other file that is always included) should verify that a path contains the course part if we're inside a course and redirect the user's browser if it doesn't. This would keep old URLs accessible, while enforcing use of new ones as discussed in http://www.atutor.ca/view/12/12246/1.html#12323.

The extra "?course=" can be a problem for some files (e.g. faq/index_instructor.php treats any unknown GET parameter with an error). So it should be handled and unset early during the execution.

At this point, all the alterations to the URL will have been removed, and most existing files would stay happily unaware it had ever changed. So their code could remain untouched. The exception is URLs output; see below.

3. About downsides.

Though a simple approach works well on synthetic examples, I wasn't able to achieve a good result on real ATutor.
First and foremost, all the URLs generated by ATutor have to be replaced. This is not as easy as just editing some constants like AT_BASE_HREF and replacing ubiquitous $_SERVER['PHP_SELF'] with e.g. $_SERVER['REQUEST_URI']. It could be much more laborious.

We have to distinguish between pages that are course-dependent and those that are not. E.g. /documentation/* should not be prefixed as it's unchanged regardless of whether it's in a course or not. It will probably make a little difference for usability, but from a search engine viewpoint it may seem strange and a site could, I guess, get penalized for breeding exactly the same pages.
The result may be achieved by adding a list of files that are course-independent into $_pages structure of include/lib/menu_pages.php, or a separate array. Then, each URL, before it's output, may be first passed to a special function checking the list and changing the path as needed, like

echo '<a href="' . enforce_new_urls($_SERVER['PHP_SELF']) . '?id=500&asc=value">' ...

Also, some problems have been reported with rewriting HTTP methods other than GET. Didn't look at that though.

4. About a similar approach to course items.

Implementing the Greg's example ("www.example.com/atutor/12/content/175") would greatly improve readability.

Probably, it can be done just like the course permalinks, and fewer changes would be required. The thing to consider is whether a similar approach should be taken to any other data inside ATutor. That, in turn, may require a different approach if the above one appears to be non-scalable (just a guess).

I don't know the search engines' policies regarding URLs containing "?"s. Quite contrary, I've seen a lot of such pages in Google search results. So if it really cares about such links, and doesn't weigh them lower, the rationale for content permalinks will become quite different from that of courses': they will serve primarily as "syntactic sugar" rather than being enablers for something really new, like the ability to be traversed by bots.
But, if Google really underestimates/ignores such URLs, these content permalinks may well be worth implementing.

5. About custom slugs.

Course slugs are useful things, and once we declare that we'll try expanding to the CMS market, they would really be essential.
Though, as I said, I'd prefer to be able to turn them off in a large installation like ours.

That's because most our instructors don't know English, and there are different transliteration rules from Cyrillic to Latin script. Often the transliterations by such people are funny or ambiguous, which, when used in slugs, would be bad for a university. In a large installation (now we have about 300 courses) there also is a potential for a conflict between some common course titles like "Physics" or "System programming". That might cause debates over the naming priority.
So we'll have to either employ a centralized university-wide policy regarding this issue, or (better) remove an ability to customize the URLs altogether.

However, in a more strictly managed or personal CMS, this feature would be nothing but a bonus.

I'll be glad to hear more suggestions and any preliminary results.

Thanks! I cannot comment much on the more technical aspects, but regarding search engines policies regarding "?"s I can say that they are not automatically ignored. I believe the policy is that they are given less weight if they are not linked to from somewhere, but if they are linked to (say, from a course catalogue) they will be indexed as search engines most often index by following links on a site. However, more "static looking" URLs are better.

But based on this, can a good road map to get this into Atutor be the following:

1. add the ?course_id=xx operator to the URLs, and confirm that this is working.
2. add a rewrite module / option so servers who support mod_rewrite can change "?course_id=12&cid=9874" to "/12/9874"
3. add a new option that can take a course id and replace it with a custom slug, so you could take the "/12/9874" and change it to "/courseslug/9874"

This seems to be the way most apps have followed towards better URLs.

Like what Indie's has mentioned, adding url queries(?course_id=xx) to some pages would produce some error message.  Though, I believe this can be fix quite easily. 

About the rewrite part, there are basically two ways of doing it: the mod_rewrite way, and the url way.  The first way is the easiest but it's platform dependent.  Mod_rewrite is only usable under Apache server and with the mod_rewrite enabled.  The second way is a bit complicated where it has to reads the url and match the query (/12/9874/) with some rules (?course_id=12&cid=9874).

On top of the roadmap that Vegard has given, we should also add the ability to enable/disable this feature under admin/system preference.