You are not required to store Safety Copies in the storage queue. If you choose not to, your Storage Queue will function quite similar to how the MSMQ's Storage Archive queue does in EV10 and earlier, at least conceptually (although that is a bit over-simplified). Work will go in and go right back out.   You can go without safety copies at all or you can leave them in the source (usually Exchange).

The backup programs with agents do not need to work "with" the EVSQ. The EVSQ will take its cue from the database; when the partition is backed up (your normal storage partition), the database will be updated to reflect the status, and the EV processes will begin to clear he EVSQ accordingly. 

The obvious challenge/obstacle is around the storage requirements, but in the grand scheme of things a customer may decide this is not that big of a hurdle in light of the benefits returned.  For our Exchange journal archving customers, I see this as a huge step forward; in the past, customers have had to choose between storing safety copies in Exchange journals till the Vault Store Partition is backed up (very impractical in even moderate-volume journaling environments-- the Exchange journal will bloat by the end of even one day) or not having any redundancy.  If you did not keep safety copies in your journal, and you ran a good backup Tuesday night but then your SAN failed on Wednesday evening, that was a whole work day of data that might not be recoverable depending on how you had Exchange set up.  To be able to offload from Exchange immediately, yet still have two copies of the data in two different storage arrays until you confirmed you had a good backup, that's a huge win in my book.  

Plus for mailbox archviing, the ability for the users to have fully functional shortcuts (move, forward item, etc) immediately *and* see their mailbox size go down ASAP without waiting for backups is going to make for some very happy end users.

I'm  happy to be able to offer this to my customers.