I read through what this is supposed to be a few times but still can't tell what they are talking about with this matrix thing.
As for thin provisioning, you need native support for it in the array *if* your array is going to be a shared resource, and the way things are going with consolidation there will be more and more arrays that are supporting more than one app.
Application level thin provisioning doesn't save much on the array side, because you have to provision a thick LUN to the app. So if you export a 1TB thick LUN and you start using VMware-based TP you can get TP at the application level(e.g. create 20 VMs each with 100GB of TP space and maybe you only use 20x5GB instead of 20x100GB). But that 1TB of data is still hard allocated on the array if the array itself is not using TP.
You could start out with smaller volumes on the array side and grow them dynamically, then somehow inform the app that the volume is bigger and it can format that extra space. Seems like a lot of extra work that can be avoided just by using TP on the array to begin with.
Also consider next gen thin provisioning which involves automatic space reclamation on the array, though transparent application support for that stuff is still tiny at this point.
as for Orcarnia, last I checked they were a file-based solution. Xiotech is a block based solution so you'd need another layer in there for the file based stuff, which to me means theres not a lot of point in trying to directly integrate Orcarnia with Xiotech.
Xiotech also does some pretty neat wide striping, and of course wide striping is the arch enemy of spin down, want to read that 20GB of data? I need to spin up 30 disks to do it..