but this seems like something better handled by revision control systems anyhow.
Integrated change tracking is a form of revision control system, embedded into some document formats and applications. It serves a different purpose than a traditional revision control system, and is useful in combination with a traditional RCS or a document management system with its own file-level revision tracking and approval systems (such as SharePoint or Alfresco).
Change tracking systems log a sequence of actions that led to the new state, store time and user metadata inline with these changes, and allow out-of-band content (comments) . The current state of a document with change tracking is (approved content + not yet approved changes + comments). In a traditional RCS, the current state of the document is just the approved content, as there's no approve/deny mechanism for individual changed sections and no metadata at the section level. ("section" here is the unit the RCS uses when differencing files - usually lines in a RCS used to manage source code changes, but in document change tracking, this is often just the part that was changed - could be a single character, could be an entire page of content, could be the metadata for a sentence, etc.)
In my view, a document should be treated as a token, and modifications to that token should be handled by external systems.
Changes should be tracked as they are made by the user. A traditional RCS tracks the differences in an entire file between the last change and the next commit, so it can't... unless every single change results in a separate (local) commit, and saving results in those commits being pushed to a new branch. But doing this requires the application to have support for change tracking, just with the backend being a RCS instead of inline metadata in the file. And then the individual changes can only be obtained and displayed to the user by getting all of the commits in the branch and replaying them, starting with the original state in-memory.
Using RCS in this way still doesn't solve the approve/reject feature of change tracking, it doesn't solve comments, and it makes showing individual changes a lot more difficult than just storing the changes with inline metadata.
Traditional RCS doesn't know how a change was made; the application does. Changing "this is GREAT" to "that is great" could be a single change (overwrite using paste from clipboard) or many changes in the order they were performed (change "this" to "that", change "GREAT" to "great", adding bold formatting to "great"). The application knows, and it can save this data.
Traditional RCS can be used to atomically track the file-level changes to a document, but it doesn't provide anywhere near the level of detail as change tracking. I don't use MS Office, but I believe it supports both embedded (in-file) change tracking and versioning at the document level (using SharePoint or something that can pretend to be close enough, which I think Alfresco might be able to do).