The CR has a published state (or live state) for one revision, noting that this is the live revision. You should be able to use this for your "locking" feature, meaning, if an assessment is enabled, do not update the live status of any change you make.
Furthermore, it is a *very bad* idea to not use cr_revisions for questions unless you make every change to a question a new cr_item (new question). Reason:
1) Professor A creates question Z.
2) Professor B uses question Z in his assessment.
3) Professor A changes question Z.
4) Professor B is notified of the change and can decide, if he wants to use the changed question in his assessment or not.
Now, if we use cr_revisions, the decision made in 4) only changes the revision. If we use as_items though, 3) triggers the creation of a new question and you have to make sure that B get's notified of that change and that all statistics across question Z take all derived cr_items into account as well (as the change might be just a typo, which would not nullify all results).
Continuing down that road, it is after all possible to reuse sections. So the same problem applies for sections as well. As for assessments, yes, if you change an assessment, you have to change the revision_id as well, unless you create a function that gives you the "live" revision based on any revision_id.
Last but not least, you have a pretty good idea, where the cr_revision is referenced, which is something you need to do anyway, because you can assume that if Prof. A changes question Z he wants to see that change in all his assessments. Well, actually I'm not so sure about this. So the UI would have to provide the professor some information about the implications of his change (e.g. show all of *his* sections where the question is used and ask for which sections the professor wants to change the question). Last but not least, every change in an assessment or a question may or may not trigger a recalculation of the final result.
To sum it up, in my opinion you have two options:
a) continue to use cr_revisions and propagate the changes.
b) use cr_items and link all cr_items that derive from each other together (which is the approach taken by the localization of content, if I'm not mistaken).
Either way is fine with me, but the implications should be made aware and taken into account when developing.
