Hi Scott.
The way we used to handle that was to make multiple copies of the course.
Suppose that the university taught semester1, semester 2, trimester 1, trimester 2, trimester 3, summer. You could have a standard set of abbreviations for this:S1,S2,T1,T2,T3,SU.
So your courses would be A101S1, A101T1 etc.
In general terms, it is a good idea to keep a "master backup" of a course and create copies of it for each semester. It is also good to archive the old course, student data and all at the end of the course, as there are issues such as appeals, and fraud discipline which only emerge later.
In the university where I was involved with (hawk, cough, spit) WebCT, we used to run course population scripts at the start of semester, and backup scripts at the end. The educational designers kept the originals. Then it is a question of writing a script to query the course and enrollment option for the student, and putting them in the right course. Unfortunately, in our case this meant having to have a layer of script between the university's student
database and the Worst Ever Bloody Courseware Tripe.
disclaimer: WebCT is a lot nicer now than then(v2.0), and it probably doesn't get corrupted when you put punctuation in the students surname -eg "O'Connor". You probably also don't get byteorder problems when you try to back up a course on a solarus box and restore it on a linux box (gotta love those nasty dbm databases inside it). I'm sure that now its internal chatserver restarts when it is shut down uncleanly. It was the best for its time, but gee it was ugly.
Leon