And perhaps all other HMT fields?Unfortunately post #10 also highlights there is also a case where the bookmarks can also be overwritten when the recording is not in use
...
This seems like a case that would be possible to trap. As the settop program doesn't seem to keep the last .hmt open (if it did, lsof could detect the situation as with the .ts), it has to open it for write which should be possible to hook through the call into uClibc.
As a more mundane approach requiring fewer geniuses, anything in the CF that modifies bookmarks or other HMT data could save a backup of the .hmt, or of just the modified data or (similar to Oatcake's plan) the modified data in a journal. Any .hmt modified by the CF could be monitored for changes with inotify.
In either case if the saved modified data conflicted with the version saved by the settop program, the new CF function would have to guess which version to preserve or how to merge the versions. One plausible heuristic would be that if a CF function had modified data from X to Y, an attempt by the settop program to save X should be overridden; using inotify, that would mean CF HMT modifiers keeping the X version as well as the Y version.