Alex - The controls on the Ribbon do not filre the ModelessOperationWillStart/Ended() notifications either, so that entire approach is flawed to begin with.
The ModelessOperationWillStart/Ended() notifications are effectively-obsolete, and the fact that they're not exposed to managed code isn't a major issue, because you can just as easily use the DocumentLockModeWillChange event of the DocumentCollection to do effectively the same thing (when the document is unlocked, that corresponds to the ModelessOperationEnded() notification).
The problem with using the ModelessOperationEnded() notification to make additional changes, is that those additional changes are not encapsulated within the same UNDO groujp/transaction as the changes that triggered the notification, and to the end user, all of the changes are part of a single, logical operation that should be undo-able as a group. Unfortunately, changes made in reaction to changes that trigger a ModelessOperationEnded() notification, will not be undone along with the original changes that triggered the notification. So, if the user issues UNDO/1 after you've made additional changes in response to ModelessOperationEnded(), only those additional changes will be undone, but not the changes that triggered them, and that is a problem.
The best possible way to deal with problems like this, is to use an ObjectOverrule, provided it is constrained using some kind of Filter (ObjectId filter, XData filter or XDictionary filter). Unlike the ObjectModified event of the Database, within the Close() override of the ObjectOverrule, the notifying object that is about to be closed can be modified, and more-importantly, any additional changes made at that point will be undone along with all other changes made prior to that, by whatever operation made them.