TL;DR, In today's environment, there is no benefit to application SW (e.g. a database system) managing writes to storage in a manner aware of bit polarity in relation to previous writes to same location. This, and other complications, are abstracted away by mechanisms within the underlying storage devices.
You seem to be unaware of the fact that SSD devices are affected by almost exactly the same phenomenon: the write block size is smaller than the erase block size.
While it is true that current NAND Flash based SSDs do indeed have the same fundamental issue you describe*, that complexity is completely abstracted from the user interface. There are no user accessible 'knobs or switches' which allow any layer above the native SCSI, ATA, or NVMe interface to dictate the physical placement of any logical block of data***.
* (incidentally, the issue you initially implied - erased flash is in a '1' state, while it takes a write to flip a bit to '0', thereby one might ensure subsequent writes to a given block only flip '1s' to '0s', is completely orthogonal to the (substitute) issue that NAND is written in pages, and multiple pages make up an erase block)
It doesn't take a rocket scientist to write a backend storage for Bitcoin with lower write amplification.
Sure, you can coalesce writes. You can do large writes. You can do sequential writes. These are things that work on HDD too, and have been known for roughly a half-century. But you cannot reach into the drive through the interface and dictate physical placement. At least not with any volume-shipping SSD.
The reason I'm writing all this is to see if there's any intelligent life left in Charles' Hoskinson's organization. I clearly can see that you are intelligent, if somewhat not-up-to-date.
No, I assure you that I am completely up to date - both with respect to shipping product, and well into things on the horizon for a good portion of the storage industry.
When a logical block is written, there is no way to dictate that it be written to a previously-written page that would require only 1>0 changes, due to the 0-bitmask of the new data being a proper superset of the 0-bitmask of the old data. Other than devices that do internal data reduction**, each written logical block is written to a physical block (part of a page) that has never been written since the last time that erase block has been erased.
**As for the case of controllers that perform data reduction, such a write ends up being a nop, as the data in the logical block already exists in entirety (in logical form) elsewhere in storage. The device merely creates a pointer to the existing data. Nevertheless, such controllers do not expose any interface by which some layer above the device might affect this behavior.
***Command standards have recently added Logical Block Markup Descriptors -- hints that certain logical blocks 'belong together' -- but these are hints, not directives, and are not yet supported by IO stacks in any OS likely to be employed as a Bitcoin node.
While I am not an SSD salesman, nor part of any Charles Hoskinson organization, I am a senior technologist in the research division of the largest developer of storage devices on the planet. Will you be at Flash Memory Summit week after next? I'd like to buy you a beer or coffee for more in-depth discussion.
