I assume you are using Windows? If so, I'm wondering if the embedded SE algorithm is oblivious to the Windows
Volume Shadow-copy Service (VSS). In other words, some Windows application sends a delete/erase command to SSD and the SSD firmware thinks it has deleted all the files, when in fact there are duplicates available, due to faulty windows originated commands. Second, also check the eMMC versions supported by your SSD. (Yes, they are not the same, but the standards still have to match, as SSD FW is very similar to that in eMMC's.) Finally, there are ways for low-level interaction with SSD firmware to find out their versions and supported features. Google for SMART report etc.
EDIT: I've revised my answer to clarify.
The above explanation was not satisfactory. Apparently there's a middle layer that is messing with what some simpler windows applications think they do, versus what is actually received/processed by the SSD firmware.
I'd like to quote this post:
"Secure Erase is embedded in the drive controller microcode and is
initiated by an externally issued command sequence. Once initiated, SE
uses an optimized single pass process that addresses all regions of
the storage media, including the Protected Service Areas (when
properly launched using compatible hardware). Protected service areas
include G-List, Host Protected Area, and the Device Control Overlay
(search Wikipedia for a detailed description of the role of each
component of the PSA).
Despite the fact that it is launched by external command, and is a
highly effective PURGE level sanitization technology it can not be
reliably launched in on most host equipment due to host controller
protection of the HPA, and the fact that many BIOS manufacturers
inhibit SE from being launched due to security concerns. The issue
being that if virus or malware were to initiate SE, the target
computer would be purged rapidly, and with no hope for recovery."
For more details on the ATA SE command(s) check here.