The UpdateRow action in an Edit Session (which you had to set up for a versioned feature class) fires all triggers for fields that respond to Modified edit events, like Feature Linked Annotation label expression fields. Basically if a Composite Relationship Class exists with a listerner for any field that you included in the UpdateCursor field list. Every time a triggers fires and causes an update elsewhere, it results in the same record being processed by the cursor twice, once before the trigger and once after.
The reason it is not consistent is that not all records have a relationship to an actual feature in another feature class. So features with no Feature Linked Annotation will only be seen by the cursor once, but features connected to Feature Linked Annotation will be processed twice. Additionally, when a record is processed twice, changes are taking place someplace you may not expect, i.e., Feature Linked Annotation triggers rebuild the annotation based on the label expression every time the UpdateRow fires on the feature they are linked to if a field in their label expression was visible to the UpdateCursor. So you are destroying most of the manual adjustments you probably have made to your annotation.
I destroyed about 2/3s of all the manual edits ever made to my Annotation before I realized what was happening and had to restore it from a backup due to this behavior. I have complained to Esri that this behavior is not documented and is not at all similar to how the Editor responds in an interactive Edit session. They have not admitted it is a bug and will most likely post it in a blog no one will read rather than in the cursor documentation. It is a huge gotcha for editors of Feature Linked Annotation.
You cannot include any field in your update cursor field list that the Editor is monitoring for Modified Edit events through a listener that triggers a Composite Relationship class behavior. Including the field in the field list and using UpdateRow while within an Editor Session on a feature is all that is required to fire the trigger, nothing else. The trigger fires even if the cursor never directly reads the field's value or never makes any modification to the field's value.
This does not happen if you can use the UpdateCursor outside of an edit session, but that is not allowed with Feature Linked Annotation Feature Classes, so in that case avoiding the Editor is not an option. See this post as well.
I mentioned that the double processing of a feature by the cursor in this situation is another problem for routines that need to count edited features, but was told I would have to log a separate issue to have Esri look at it. Since I now will only use the UpdateCursor on fields that the Editor never listens to so that I never again destroy my annotation, I won't be triggering the double count behavior again either.
