A bit more information:
The way flash memory works, it needs to be erased before writing to it. This is a bit different than spinning magnetic disks, where you just overwrite it. Writing new data to a blank disk and writing data over existing data were identical in performance.
As a result, with magnetic disks, the classic way of deleting a file or formatting a partition was just to delete references to it - the actual file contents would still be there. On flash, this was not optimal for performance because writing to blank blocks is much faster than writing to a block that has info on it because that block must be blanked first.
Eventually, the TRIM command was added to various operating systems, such that when a partition was formatted or a file deleted, the OS could tell the flash controller that those blocks were no longer used and could be erased immediately. It makes the wear leveller's job easier to have a list of "unused" blocks.
I believe MMC_CAP_ERASE is related to TRIM (I haven't had time to figure out the exact differences) - even with TRIM disabled, it seems to make a difference. Gingerbread kernels and I9100 ICS kernels don't support TRIM or ERASE. ICS kernels for SHW-M250S/K/L support ERASE - and these seem to have a risk of hardbricking or permanent eMMC damage when you do a large ERASE - confirmed for a wipe in CWM and any operation that wipes first, suspected for wiping in 3e recovery of a non-repacked leak kernel that is affected, and I suspect a large file deletion (such as a video file of hundreds of megabytes) may also be risky - but I'm not sure.
It seems like ICS leaks for the Epic 4G Touch, AT&T Galaxy S II (SGH-I777), and the Galaxy Note (GT-N7000 and GT-I9220) have the same issue as the SHW-M250S/K/L kernels based on reports. Unfortunately leak kernels don't have source so there's no way to tell what changed, no way to know which ones are dangerous and which ones aren't. For this reason I don't trust any ICS leak kernels for the above devices.
This may be a problem only for a small percentage of users - 1%, 2%, maybe as high as 5% - who knows. Other people are fine with the affected kernels - for example Task650 and ktoonsez never had any issues with the UCLD3 leak kernel, but others hardbricked. gokhanmoral was able to wipe multiple times with SiyahKernel 3.1rc6 (based on SHW-M250L ICS sources instead of GT-I9100 ICS sources), but others hardbricked or experienced permanent damage when wiping.
Right now, MMC_CAP_ERASE seems to be the suspect - but no one can be entirely sure without:
Source code for leaks of affected devices that don't have source (Note, E4GT, I777)
Taking dangerous risks such as trying to reproduce the problem - if you reproduce it, it's time for a motherboard replacement.
The only thing we know for sure is that the GT-I9100 ICS leaks and official releases seem safe, as are kernels built from the I9100 Update4 source drop, as are all known Gingerbread kernels for any device.
