For actions we have:
https://www.zabbix.com/documentation/3.0/manual/web_interface/frontend_sections/configuration/actions

If an action is disabled during an escalation in progress (like a message being sent), the message in progress will be sent and then one more message on the escalation will be sent. The follow-up message will have the following text at the beginning of the message body: NOTE: Escalation cancelled: action '<Action name>' disabled. This way the recipient is informed that the escalation is cancelled and no more steps will be executed.

Something similar is mentioned in section "An action is disabled during an escalation in progress (like a message being sent)" here https://www.zabbix.com/documentation/3.0/manual/config/notifications/action/escalations

Similar things happen for other cases too.
Here are suffixes added after "NOTE: Escalation cancelled: " prefix:
if event is already deleted:

*error = zbx_dsprintf(*error, "event id:" ZBX_FS_UI64 " deleted.", escalation->eventid);

for trigger events:

*error = zbx_dsprintf(*error, "trigger id:" ZBX_FS_UI64 " deleted.", triggerid);
*error = zbx_dsprintf(*error, "trigger \"%s\" disabled.", trigger.description);
*error = zbx_dsprintf(*error, "item \"%s\" disabled.", items[i].key_orig);
*error = zbx_dsprintf(*error, "host \"%s\" disabled.", items[i].host.host);

for internal (only) events with trigger object:

*error = zbx_dsprintf(*error, "trigger id:" ZBX_FS_UI64 " deleted.", triggerid);
*error = zbx_dsprintf(*error, "trigger \"%s\" disabled.", trigger.description);

for internal (only) events with item or lld rule objects:

*error = zbx_dsprintf(*error, "item id:" ZBX_FS_UI64 " deleted.", escalation->itemid);
*error = zbx_dsprintf(*error, "item \"%s\" disabled.", item.key_orig);
*error = zbx_dsprintf(*error, "host \"%s\" disabled.", item.host.host);

the case which already mentioned in documentation, with another one which is not:

*error = zbx_dsprintf(*error, "action '%s' disabled.", row[1]);
*error = zbx_dsprintf(*error, "action id:" ZBX_FS_UI64 " deleted", escalation->actionid);

But such server behavior is not described in documentation for mentioned entities in "Status" property.

It's a inconsistency and probably could be fixed.