If I understand the pool architecture correctly with regard to Thin Pools though is that the entire pool is not one "RAID" group, so a group can survive multiple disk failures. I think I remember reading that it was similar to RAID5 4+1. If it was otherwise a Thin Pool would be less redundant than a traditional RAID group.  I personally woldn't use 10 disks only to create a thin pool, that is too few for a good distribution of the data. The best practices (again if I remember correctly) was to use a minimum of 20 disks in a pool and to add disks in increments of 5 disks at time. So with only 10 disks to use I would stick with a more traditional RAID group approach.
Hypothetical question to help me get some better under standing of Thin Pools.  With a CX4-120 running ver 29.  I want to migrate an Exchange environment to a new CX, normally I would put the Exchange DB's on different RAID groups than their corresponding Trans Logs.  Say I have 10 FC disks that are available to use.  Traditionally I would create two RAID groups and put the Exchange DBs on different RAID groups than their corresponding Transaction Logs.  I would do this to help spread the log, but also from a data recovery perspective in case a raid group failed and then failed again during a rebuild, i would always have at lease the logs or dbs.  But if I go down the Thin Pool route and put 10 disks into a single Thin Pool, if there were a raid failure and the rebuild of the raid had a failure would the whole thin pool be unavailable?  Any suggestions, I can't seem to find these answers in the documentation?  Thanks.
Thin Pools and Exchange DB vs. Logs