To reproduce the issue:

1) Accept an event invitation from kmail that you are not the organizer of (not sure if this is really necessary but it is the case that I fully tracked down).
2) Edit the event in korganizer and be careful to ONLY add an alarm.
3) Get the event organizer to send you an event update, for example, with a changed location.
4) Observe how the location change is shown in "reverse logic".
5) Try to accept the changed invitation and get the "This is not an update" error.

What happens under the hood:

Step 2) above should not lead to an increment of the event revision (iCal SEQUENCE property). At least that is the intent of the allowedModificationsWithoutRevisionUpdate logic in akonadi-calendar/incidencechanger.cpp lines 1022ff.

Two things are going wrong, though, and if you watch the actual akonadi payload (e.g. in akonadiconsole), you will see that the revision gets incremented TWICE!

So by the time the organizer sends an update, the local copy is seemingly newer, leading to the incorrect display in kmail as well as the error in Steps 4) resp. 5) above.

One of the revision count increments is caused by lines 657ff in incidenceeditor/incidencedialog.cpp. This seems to be an unconditional increment in this context and I have no idea why it would be there. It appears to preclude any form of "smart" handling of changes within akonadi.

The other revision count increment is due to a failure of the allowedModificationsWithoutRevisionUpdate logic mentioned above. In that function, the dirtyFields() call on the incidence returns many more fields than just IncidenceBase::FieldLastModified and IncidenceBase::FieldAlarms. On my machine it lists a total of 10 fields, including FieldRevision due to the previous increment in incidencedialog.cpp.

The issue seems to be that some of the modifier methods in IncidenceBase and its children set the respective dirty flag even if the value of the property has not changed. For example, setOrganizer in IncidenceBase does not check the previous value and setSecrecy in Incidence or setTransparency in Event fail similarly. On the other hand, some of the set methods do this correctly, for example setUid in IncidenceBase. On my machine, I have observed incorrect behavior for Description, Recurrence, Attachment, Secrecy, Transparency, Attendees, and Organizer (and possibly for Alarms and Revision as well, but that might be confounded with the other issues described here).

Additionally, toggling the alarm on the event (e.g. via the context menu in korganizer) seems to set IncidenceBase::FieldUnknown in dirtyFields() where it should probably be FieldAlarms. With FieldUnknown, toggling the alarm causes similar issues as described here.  

While you are fixing this, the logic in allowedModificationsWithoutRevisionUpdate should probably be expanded to also allow modifications of Categories (not 100% sure about this but I would think that categories are a local property given that they map to akonadi tags). Many people are colour-coding their agendas using (local) categories and in the current implementation that breaks invitation updates.

I am more than happy to try suggested fixes if needed.