Created a PR (#419) where implemented the 'delete meta' functionality. Doing checks during post re-distribute (in the SubscriptionsController::receive_item(..) method) by comparing stored previous request meta data (stored in dt_subscription_update post meta key) versus new one and deleting post meta which existed in previous request but don't exist in the current one.

We have discussed this issue with @avag-novembit and I would like to add my thoughts, hopefully it will give more info about our approach and explain PR sent by @avag-novembit.

The basis is following - It's a must and it's safe to delete part of the post (in this case post meta), if it has been added/modified by Distributor. In other words, if will delete part of the post, that has been generated by Distributor, it's OK and expected, but if we will delete non-distributed data, somehow generated in directly destination - it's not OK and unexpected.

For example, we may have a plugin in source and destination, and that plugin can add/update a meta on certain events, it may also delete this meta from all posts on deactivation, now, when we will deactivate this plugin in source and then update a post, Distributor will delete this meta in destination as well and this can generate unpredictable issues, but this issues are expected for destination site maintainer, the same way we could have issues when we were adding meta data from source.

Deletion will be unexpected for maintainer if Distributor was never distributed that data, but all of sudden will decide to delete it. That's why we want to make sure that the most recent update from source brought this data, that we want to delete now.

I'm not sure if we need to compare meta values too, in case of duplicated meta keys it can be really important, but from the other side, we have many filters allowing third party code to extend and modify meta values before they will be inserted into DB (for example our ACF addon will map the meta value, if it contains an attachment ID), however, in my point of view, this data is still added by Distributor and has to be deleted, so, comparison with meta values needs to consider this modifications as well.

I'm moving this to the Future Release milestone to be considered alongside a broad approach to how we handle meta removal/deletion from remote sites. Apologies for the delay on response to this one @arsendovlatyan, but I want to be cautious with how we handle meta deletion.