One may install triggers that run on replace to a space, see space.on_replace, space.before_replace. Historically, these triggers are fired not only during normal operation, but also when memtx data is recovered from snapshot and xlogs. Such a behavior is confusing because:

• One has to write triggers with this peculiarity in mind. For example, if a trigger is used for some kind of data exporting, it should be skipped during recovery because the data must have already been exported before restart.
• These triggers do not work with other engines. For example, in case of Vinyl, the behavior is undefined: a trigger may or may not run for a statement recovered from an xlog, depending on whether it was dumped to disk before restart.
• Using before_replace triggers on recovery is dangerous because it may break recovery. Even if it doesn't, one may get a database state, in which the in-memory data is different from on-disk data, which may result in weird breakages later.
• Supporting triggers on recovery slows down startup because we have to run all statements recovered from the snapshot through the transaction manager, see Recovery performance regression (-1.5x on SSD) #11452.
• Handling the triggers complicates our code. We have to disable certain features if triggers are set, e.g. see Save order of secondary indexes to snapshot #10847.

The suggestion is to deprecate the feature under a compat option. Note that in the new triggers API we have a special name for a space replace trigger fire on recovery - it's on_recovery_replace and before_recovery_replace. These triggers should be deprecated and eventually dropped, as well.