Probably not impossible (I backed the CHIP project at the level that gets me an early board and five more when they're shipping, so I'm excited). The specifics I've seen for CHIP don't look too encouraging for either SD card shields (their answer: "use USB") or SCSI (it would have to be bit-banged). Bit-banging a SCSI interface on Linux is not something I really even want to think about, because it's really a piss-poor GPIO layer. You really want something closer to the metal, which is possible on the RPi and should be possible on the CHIP. This is something that a Linux stack makes considerably harder, not easier.
A small embedded micro (as used in SCSI2SD) is really the optimal solution, and I'm confident that it can be done cheaper than SCSI2SD for someone with the time and expertise to invest.
I backed a CHIP board as well, so it'd be a nice application for it if possible. I would be OK with it just using the onboard 4GB of flash storage. Maybe it could use the USB ports for flash expandability. If it could cost something like $15 for a SCSI shield, I think they would sell very well along with the CHIP.
I just checked on the SCSI2SD project, and it looks like the board got totally revamped again and the cost is better. It is now $75 for the smaller board. Not a bad price for an enthusiast, but probably still not low enough for something like putting one in every working machine that you have. It seems fairly stripped down now, can it be done for less? The artmix board is $125 and somewhat higher performance, but probably not compelling enough to buy vs. the SCSI2SD.
My gut feeling is that in sufficient volume, you could get something like SCSI2SD down to a unit price of less than $40, especially if you have it fabbed and assembled in China. You need volume in the 1k-10k to make that pricing work, though, which is a lot more money than I'd be willing to gamble on a vintage computer product (I'm already nervous about the ~$1400 I put into getting parts/PCBs for ~125 IIfx SIMMs, but that's at least likely to sell out).
Finding a suitable micro that does SATA is proving to be challenging. The "suitability" aspect is really mostly a question of the external bus. The best contender I've identified yet is the AM1808, which is an ARM9 with a SATA interface on it. The external bus sucks for making synchronous SCSI work, though; it's made only for SDRAM or asynchronous accesses.
The STM32F446 is actually almost perfect for the SCSI end (coupled with an external CPLD to handle the actual SCSI details); it has a synchronous external bus with proper wait states that should be able to support up to Ultra160 SCSI. Buuuuut it doesn't have SATA. Its SD/MMC interface goes up to 45 MHz in MMC's 8-bit mode, though, so you could realistically get Ultra SCSI speeds with it.
The OTHER option is doing it all in an FPGA, which would let you get to much faster SD card speeds and do SCSI the "right" way. You could also add an ATA interface practically for free. You can get a EP4CGX15BN11C8N (the smallest Cyclone IV with transceivers) for about $23 in single quantity; you could probably drop that by about 25% in 1K quantity. It would likely be a slightly more expensive solution, but considerably more versatile. Only problem is doing all that in an FPGA is a LOT of work, unless you want to buy a SATA IP core, which costs a fair chunk of change. Having the SD and SATA peripherals available in the micro is handy, plus you have a processor to control it all instead of either dropping in a soft processor (lots of time and/or money) or doing it all in state machines (not ideal).
As for faster speeds: doing LVD makes it all very expensive, because the SCSI transceiver ICs are decidedly not cheap (SN75LVDM976 is $16 in 1K qty, and you need 3 of them for a fast/wide connection, plus they're at lifetime buy stage so they won't be made for much longer). Single-ended can be done cheaper, but that realistically probably only gets you to about 10 MHz (still fine for any SCSI Mac using stock SCSI, less interesting for the workstation/server market).
One of these days I need to take a longer look at what can actually be done with the PSoC chips and their customizable array. That could take care of a lot of the SCSI stuff if desired. SCSI2SD only uses SPI mode of the SD/MMC card, and doesn't do synchronous SCSI transfers, so there is room for performance improvements (at least on machines featuring SCSI Manager 4.3-level hardware, and some of the other architectures I mentioned).
You won't be able to bit-bang synchronous SCSI with a microcontroller (well, maybe at 5 MHz you could, but I wouldn't), but it is potentially possible using a CPLD and a synchronous external bus. I need to drop a logic analyzer on a fast SCSI bus sometime to have a look at some real transactions to make sure; there are a few potential clock domain crossing issues that concern me that would be taken care of perfectly with a real FIFO, but you don't get those in a CPLD.
Anyway, long message, but I hope it conveys some of the design space parameters I've been thinking about.
OK, a quick addendum: I'm looking through the architecture manual of the PSoC 5LP architecture, and I like it A LOT for SCSI. The programmable logic part of it is a bunch of PLDs similar to (but in many ways better than) PALs plus some very nice datapath blocks that include ALUs and real FIFOs. The interface to the system bus is 16-bit, which should support wide SCSI, and it interfaces with DMA. And it's all programmable by the user.
Overall, I gotta call this architecture a win; it's come a VERY long way since I saw the first ones come out, which would have been more accurately named PoS. I'm glad they stuck with it and opened up the architecture. This is going to be at the front of my mind for any project that needs custom logic from now on.
Last I caught up with the SCSI2SD thread, mcmaster was moving his SCSI handling into the programmable logic on the PSoC5. I believe that's open source, but if not he might be up for sharing his code if you ask nicely.