On base of a standard incremental replication package the initial load (i.e. contact) loads all records, except those, which are in the recycle bin (isDeleted = 1). This works as expected.
In the phase of the following incremental load the data is loaded for as specific time window after the last load (datetime) and the current system time on the base of LastModificationDate.
If a user now puts some objects in the Salesforce recycle bin, the LastModificationDate is presumably not affected by this action. Nevertheless it's expected like with the initial load, that binned records also no longer should exist in the target object or at least the isDeleted attribute value should be updated accordingly.
But given the current situation the time window of the next incremental load (related to LastModificationDate) does not consider those records for replication and the records remain unchanged in the target database (i.e. Azure SQL). This results in a data inconsistency between Salesforce and the target database.
After 15 days or a manual clean-up of the recycle bin, the next replication reflects the change as expected and removes those records also from the target object. Maybe due to the fact, that now Salesforce also updates the LastModificationDate value ...
Skyvia should preferrably consider the SystemModDate instead of the LastModificationDate for the evaluation of potential replication records and/or should additionally always consider all records with isDeleted=1 - independent of any date values.