>All good and well seen from operating within the typical way of a dir/file system, but dd "copies" have to be supported as well and they are. Otherwise cloning via sector (which is last resort when in trouble) might itself be in trouble.

SSDs have no concept of a "sector", the controller is mapping them to blocks. Utilities such as dd cannot depend on the physical geometry of SSDs. dd can only get the contents of that nominal "sector" as mapped/unmapped by the SSD controller.

For desired "sectors" that map to blocks with data, the controller will map from block to the expected "sector" layout and return the results.

Empty blocks/sectors: An SSD controller could make use of a number of lists to track partitions, partition sizes, files belonging to partitions, blocks representing empty space in a partition etc. If it's smart it will use whatever is the fastest method to determine whether a desired "sector" is empty. If it's empty it can generate and return whatever representation of "empty" utilities such as dd expect, without having to read any actual block at all. Unless there are other considerations I'd be surprised if a dd-type clone of a partition or set of "sectors" actually causes any read activity on the SSD for empty "sectors"/blocks.

This seems like an opportunity for SSDs to implement (in hardware) so-called "smart" cloning which you see with more advanced cloning utilities (i.e. not cloning empty sectors/blocks).