Due to TRIM bugs I just follow an advise of never using it. Rather I set aside like 5% of disk that is never touched. This works with both old and new SSD without affecting long-term performance on laptops. As an added bonus it makes full-disk encryption more sound.
A quick Googling shows it exists only in high-end SSDs, but the information is from 2013.
Just anecdotally, my Nexus 9 does not even have the fstrim command anymore, nor do I see any discard options in the fstab. My Nexus 7 2012 had lots of interest about fstrim improving performance, but not my Nexus 9. I assumed the TRIM issue had disappeared.
Uhh... The nexus 7 and 9? You realize those have SD and MMC cards soldered to the motherboards and work /entirely/ unlike an SSD, right?
Also, the OP is right: TRIM works by telling the SSD which blocks that were previously used are now unused, so that the SSD, at a lower level, can eventually erase the larger flash sector. There is literally no way for the SSD to know this intrinsically because SSDs do not expose a filesystem interface.
Regardless of the differences, the Nexus 7 used trim (introduced in Android 4.3) on it's flash-based (SSD also uses flash) solid-state memory and my Nexus 9 does not. The trim "bug" is well known for some Android devices, but now it has died off. I was attempting to guess why.
Another quick Googling seems to say improved garbage collection (in the SSD itself) has lessened the need for fstrim.
Hopefully someone who is knowledgeable will chime in.
trim is implemented in the controller in that a controller implementing trim is capable of receiving, understanding and acting upon the trim command. It's actually issued higher up in the stack; I've only ever seen it mentioned in the context of an OS issuing the command to the drive if a file on a filesystem on the drive is deleted, or if a utility intended to issue trim against all empty blocks was run.
You're correct in that trim is less necessary if a drive has good garbage collection. I don't know anything about the implementation of either, but I would expect trim to be easier, cheaper and better than GC. It seems like GC would require work to discover/remember things provided as input w/ trim. I've assumed that GC was only implemented by vendors in their controllers because trim wasn't available in the popular OSs yet, and/or because their controllers were already doing most of the work required by GC anyway so it was cheap to implement.
Finally, you can't equate SSDs with the SD or eMMC used in some of the phones/tablets. Yes it's all flash, but an SSD is typically multi-channel with many flash modules, a DRAM cache and a much more sophisticated controller implementing a standard storage interface (AHCI/SATA or SAS or NVMe). eMMC and SD are much simpler, cheaper and slower.
http://www.tedunangst.com/flak/post/lessons-learned-about-TR...
I do believe it supports trim, since 2011. Need to check the code if and how it's implemented today.
I'm using 2 SSDs in a RAID-0 with OpenBSD for 1 year now. No problems and lightning fast.