MacStories points out there is a small, but perhaps important, difference in the "SSD+HDD" option on the new iMacs. You used to simply get two drives you had to manage separately, as in the screenshot here taken from my MacBook Pro (in which I long ago swapped the optical drive for an SSD). For the new models though, Apple now specifically states: "if you configure your iMac with both the solid-state drive and a Serial ATA hard drive, it will come preformatted with Mac OS X and all your applications on the solid-state drive. Then you can use the hard drive for videos, photos, and other files."
This may suggest a change from the older models, where the SSD came with OS X installed on it, but the HDD was blank. As OS X helpfully stores various files under your /Users folder, this (by default) ended up on the SSD. Users had to take special action to put files on the HDD instead of the SSD. There's been some speculation that Apple would do something different in these new devices, perhaps by placing the OS on the SSD and mounting /Users on the HDD to try and give users the best of both worlds.
As someone who has a hybrid setup exactly like this today, it strikes me as a rather un-Apple solution because it's fiddly, complex, and it requires the user to stop and think on a regular basis. I use a 64 GB SSD as my boot volume and /Users/rich on the boot volume is a symlink (note: see update at the end of this post) onto the 500 GB HDD unit. My OS X install, my /Applications folder, and my Aperture library are all on the solid state drive; pretty much everything else, like my Aperture masters, iTunes library and so on are on the magnetic drive.
This isn't a bad compromise, but it's still hard to look after.
For example, I recently had an install of Xcode fail due to lack of disk space on the SSD, and I had to move my /Developer folder from the solid state disk to the magnetic one. Xcode is enormous (7.64 GB for me right now) because it contains tens of thousands of files that make up various versions of the iOS SDK, but I don't care about most of these -- just whichever version I'm using at the time.
You could expand this reasoning to OS X itself. As a sprawling, modern OS there's bound to be huge amounts of its 5 GB of disk footprint that I, personally, never use. Ideally, I'd like a way to put only the parts I do use on the valuable SSD space, whilst relegating things I rarely or never need to the cheaper magnetic storage. Similarly, there are files and folders under my /User/rich folder like my Documents one that are small and I would like fast access to -- but I can't easily relocate files on a one-by-one basis.
Of course, one way to solve these problems is by simply buying a big enough SSD to hold every file you have, but please let me assure you that TUAW doesn't pay anywhere near enough to make that a financially viable option!
There is another way, however: make smarter use of the SSD space.
This is where the story gets interesting. Both tonyx86 and iFixit have found that the iMac uses the new Intel Z68 chipset -- so new, in fact, it hasn't even been generally released yet. It seems Apple and Intel's close working relationship continues. Z68 has a new feature called Rapid Storage Technology SSD Caching, which is something approaching the holy grail of SSD systems.
The system is fitted with a large HDD and a small, affordable SSD, but it only shows a single drive volume to the operating system. It monitors which files and programs you use a lot and automatically relocates those to the SSD for maximum speed, without requiring the user to ever think about which drive a given file is on. Perfect. This is similar to how hybrid drives work, but they typically only have a few gigabytes of SSD cache; that's not large enough to hold all your regularly used stuff.
MacStories speculates that this SSD caching technology will be in place for the new iMacs, but there is an important limitation that means this might not happen. Both Tom's Hardware and SSD Freaks (amongst others) reported from the Intel Developer Forum that the maximum size of an SSD used as a cache is 64 GB; Apple only offers 256 GB units for installation in iMacs. We've asked Intel to confirm this, but if these sites are correct, then it's unlikely that Apple will deploy SSD caching. It's possible that it will use part of the SSD as a cache and leave the other 192 GB free for user data, but then you're back to asking the user to manage two volumes and shuffle data back and forth between them.
Build-to-order lead times on the new iMacs with any SSD option (not just the HDD+SSD ones) are 4-6 weeks, so it'll be a little while before someone out there gets their hands on one and we can find out for sure -- unless there's an Apple store with a display model we can examine.
UPDATE: somewhat tangential to the new iMac discussion, several commenters have asked why, on my MacBook, I used a symlink instead of moving the home directory in System Preferences. This is a very good question. The answer is that I did both, but I'd completely forgotten about the preferences pane bit when I wrote this post earlier. I did that change first, when I first fitted the SSD, but I found some niggling problems with a few apps -- some smaller and older utilities wouldn't install cleanly under that setup, probably because they don't support the relocated home folder. If I recall correctly, iMovie was particularly troublesome; it would refuse to write to my /Users folder for no reason that made any sense to me. In the end, I added a symlink on the SSD file system, all those problems went away, and I promptly forgot what I had done.
Commenter Josh suggested mounting the hard drive directly under /Users, and quite rightly points out that's trivial under most Unix OSs. I know exactly how to do that on Linux and Sun OS, but I have no idea how to do it under OS X, oddly enough, because I've never needed to configure the disk subsystems at that low a level. I'll research it and write a future TUAW post about it if I can figure out an elegant method.
Thanks for your comments, guys. I really appreciate your feedback.