I like your idea of integrating Delphix more tightly with RMAN. One strategy to tie Delphix more tightly in with RMAN is to make Delphix a backup device which some customers are doing already. Some customers use Delphix as a backup for their databases. Delphix provides awesome logical recover options, for example if a someone drop a table on production or somehow damaged the data on production, then one can spin up a virtual database in minutes and get the correct data back.
Delphix can also be used for physical recovery in the case of physical corruption. When there is physical corruption one can copy the uncorrupted file from Delphix on to the source database and recover.
Delphix can be used as a fail over if the source goes down.
Delphix can restore the source completely with an operation called “virtual to physical” (V2P) where the whole database is written from Delphix back to the source.

From the second webcast with JL I understood, that my original impression was entirely wrong, and Delphix would be in fact sitting *outside* of the Production storage access path, merely sending delta changes (via custom SBT library rman incremental archivelog backups) to the Delphix server, and processing them there to create a virtual image of Production as of any distinct version of the DxFS root block, and the only load on top of the actual Production, would be the added CPU+IO load of the frequent custom incremental rman backups (would be good if these could be directly used as Production backups – i.e. made accessible as rman backupsets if Production would need a (partial) rman restore – so that there would not be a need for a double rman-backup done on Production – once for Prod backup purposes, and once by/for Delphix).