Right track, wrong solution
I have put much thought into this since I've been developing data recovery algorithms since the days when 20 megabyte drives were considered a luxury ;)
The concerns involved at this point are more related to the fact that on power up of the drive, possibly before the controller itself becomes active, the drive begins to flush its "mark for deletion" cache. This occurs by sending the delete block command to the Flash memory chips for the blocks that are to be readied for writing. This is an important thing to do as you would want to flush these sectors are quickly as possible to avoid issues related to power losses. After all, if the mark for deletion table is run multiple times, then extra writes will occur thereby degrading the sectors more rapidly. It's just a good algorithm to follow.
The drawback to this approach with regards to forensics is that simply powering up the drive, even attempting to burst a "do no write" or "enter forensics mode" command over the controller probably would not issue quickly enough to avoid the drive being written to and therefore rendering the drive as altered and invalid with regard to evidence requirements.
Forensics MUST copy the drive unaltered, sector by sector to an image which can be used to recover the media, leaving the original drive in tact before any analysis occurs.
The correct solutions would be :
1) require a jumper to be present on all devices to block garbage collector from initializing.
This solution sucks because it would take another year or two before the jumper is present and therefore would only be ok for newer drives.
2) require that the controller of the drive is flash programmable from a JTAG circuit so that the firmware can be altered in an environment where the flash chips themselves are not powered up. This also sucks since if I were the one being prosecuted, I would argue that this modification also counts as altering the contents of the drive.
3) program a controller chip separately, then desolder the original controller chip and solder the forensics controller chip to the board. This solution is great, but requires that the forensics firm physically "damage" the device in question. I'd imagine that very quickly the quality of the forensics companies' surface mount rework technicians would come into question and would quickly become an issue as to whether they altered the data accidentally.
For part suggestion 2 or 3, the next huge problem is, can you reliably keep track of all those chips and firmwares. There will be thousands of different models and revisions in the future.
4) access the JTAG ports for the individual flash chips (they should probably be accessible on all devices), then power the chips up and perform a JTAG read of all the data. This is slow and boring, but it is 100% reliable and it is 100% guaranteed to not alter the physical device or the data on the device. Therefore leaving the confiscated device in pristine order.
As a data recovery "expert". I recently recovered "all recoverable data" from a RAID 0 stripped set which someone had actually formatted and installed a fresh copy of Windows XP on... one of the drives. Having done this by imaging both drives and developing a tool to detect the raid parameters and reassembled the striped set into a single linear image from which I reconstructed as much of the original MFT as possible and then recovered images through algorithmic steps followed by a brute force method of scanning the image for JPEG jfif signatures and then reassembled photos by using simple linear reassembly as well as scanning "likely places" for missing sectors. I feel pretty comfortable calling myself a hard drive data recovery "expert" which means, I'm pretty good at it, at least good enough that I'll recover more data than most people will from a drive unless needing a clean room.
At least in my "expert" beliefs the only correct method of performing Flash based forensics is to :
1) create an image file via JTAG of each individual flash chip on the device.
2) copy these images to an identical device
3) find out from the device manufacturer how to read the sector mapping table from the controller via JTAG.
4) upload the sector mapping table to the duplicate device.
5) image the device in question to a forensics workstation
6) work from the image files.