Internally, all SSDs essentially implement a database of disk sectors, the equivalent of a log structured filesystem with a single file, due to the inability to overwrite existing data in place. A power loss without backup capacitors places the integrity of that database at risk, which is why any power loss can lead to the loss of completely unrelated areas of the logical device, not just areas with pending in flight writes, and often the contents of the device in its entirety.
It is conceivable that with extremely careful design an SSD could be designed to provide power loss protection without backup capacitors but apparently no one has managed to do that yet - or at least not with adequate performance. Take a good look at the design of something like ZFS for a clue as to how one might go about doing that.
The ZFS designers have an advantage though. Filesystem APIs make a distinction between data that needs to be committed right now and data that the user doesn't particularly mind being lost for the past thirty or forty seconds before a crash or power failure. Disk interfaces generally do not. When the FS asks the disk to flush all outstanding writes to persistent storage it had better commit in a hurry, tens of milliseconds not tens of seconds from now.
The problem here is that consumer grade SSDs cannot commit transactions reliably in the presence of power loss, and often cannot recover their own internal databases to some sort of useful consistent state after a power loss either. It is amazing how fast you can make a filesystem go if you remove all the safety features. Same deal here.