Well my phone Flash based storage space looks like a disk and smells like a disk to the computer on the end of the USB Cable. What’s that… yes if we look at the data we can see that the computer is sending SCSI disk commands to the phone. Still not convinced… it’s asking for the number of disk LUNs the drive supports.
Android thinks it’s a disk… it’s running a disk filing system over the Flash
Walks like a duck and sounds like a duck and even smells like a duck… it’s a duck! 
although disk describes a shape, and a microSD or onboard storage is not very disk like in shape
On the application and transport layers perhaps, but go lower down the stack to the interconnect and phy ( where I live ) and its different.
Command interpretation must be different, some of the OPCODE instructions used for a Hard Disks surely won’t be handled lower down in the same way.
All the top stuff just makes it easier for the OS to view it as the same, otherwise there would be substantially more work involved.
I have never been tempted by the Pigremote - I have a bluetooth interface to handle CAT. For for rest I really liked the look of VK3WAM’s design, but I don’t think that’s available now?
If you want to build an interface rather than buy it built, Wolfgang publishes his circuit free for all to use (in fact this is all he did to start with until someone approached him with the idea of selling the unit built).
All details are in the user manaul here:
Ed.
Indeed, at the OS layer, it is presented with a SCSI (or SATA) disk interface by the drive controller, but there are many layers of complexity there. Even your spinning platters kind of disk these days has more flash cache in it than some of the early spinning disks I owned. So, it’s no longer simple to say this thing is rotational or this thing is flash. This is nothing new: SAN storage has been presenting large bunches of disks with write-back cache as a single LUN to a fibre-attached host for years; it’s just shrinking a bit now.
On the other hand, it’s wrong to imply that SCSI is only designed for rotational disk; the interface has been developed continually since before dirt was invented and modern additions (like the TRIM command) only make sense on non-rotational storage.
What this means for the OS is that it has to be made aware of the underlying architecture of the disk (via SCSI commands) so that correct decisions around IO scheduling, cache flushing, page alignment etc can be made to optimise the lifetime and performance of the underlying storage.
On a Linux system, /sys/block/sdX/queue/rotational should be 0 if it’s flash or 1 if it’s spinning platters. There are other functions exposed via that interface that the kernel uses to determine the correct thing to do. This applies to Android too, as it is ultimately Linux based.
It won’t stop you from yourself, however. For example if you insist on using journaling filesystems like ext3/4 on flash storage: this can dramatically reduce the lifetime of the disk as the location of the journal does not move on disk and is frequently read-modify-written. You can hit the 1,000,000 IOs lifetime on sections of your flash disk very quickly (within hours/days depending on load) if you are not careful and suddenly the filesystem is cactus.