PVS 7.x, Citrix UPM, XA 6.5, & AppV 5.0 SP2 HF4 for Stateless Shared Desktop

Question

Note:  I have read and followed this tech net recommendation closely as the basis for my technical design (I have also read many other articles, Citrix recommendations for UPM, Microsoft Performance Guide, etc):
http://social.technet.microsoft.com/wiki/contents/articles/25318.app-v-a-configuration-template-for-deploying-to-stateless-rds-clients-on-citrix-published-desktops-with-citrix-upm-for-profile-management.aspx
I have a few questions and I'd be interested in community thought:
1.  In this design they are placing the PackageInstallationRoot on a persistent locally attached drive, which they then have to spend time wiping at every startup.  This can be incredibly time consuming to do all the icalcs commands if the AppV
Package Cache has a lot of apps (~10 minutes for my environment with 6 apps).  Is there a flaw with placing this within Non-Persistent space instead (i.e. RAM Write-Cache with Disk backing in PVS 7.6).  Rationale:
A) It is a much quicker wipe than the linked approach.  PackageInstallationRoot gets completely wiped instantly upon PVS Target reboot.
B) I could place this on my persistent volume and do the lengthy cleanup on startup, but this is the same SAN-attached persistent volume that PVS Ram Cache with Disk Overflow uses so I am not sure I see the benefit.  Perhaps there is a bit more overhead
to run to PackageInstallationRoot through PVS WriteCache overhead instead of direct filesystem call to SAN Volume, but that is the only thing I can think of.
2.  Direction talks about the exclusion to AppData\Microsoft\AppV, but for environments that use Folder Redirection for AppData I don't believe this is possible?  I'm guessing they are using UPM for AppData and LocalAppData.  I have implemented
all other exclusions (LocalAppData, HKCU Registry, etc) except for AppData and don't see any problems.
3.  Author states apps are available for users immediately, but there has to be overhead for the very first user for each app after every reboot in order to re-populate PackageInstallationRoot and Re-Publish the app.  The only way I can think to
reduce this burden a bit would be to either A) Cache (Add-AppV) application into the master image (not ideal for us), or B) have a script that caches (Add-AppV) application whenever a PVS Target boots.  This would just leave the user having to publish,
which appears to be quicker based on my testing.
Thanks

Answer 1

I would not recommend this and keep the package cache and the client on the same non-persistent drive and enable the Shared Content Store. If you separate the cache and the App-V client they could get out of sync and strange behaviour can occur. 
You can use a temporary local profile with Citrix UPM or UE-V and specify what to roam/save.
You can use the Shared Content Store so packages will stream over the network. When the user logs on there is a publishing phase where shortcuts etc are created for the user, this will take some time.
Are you using the App-V full infrastructure?
Are you using a boot disk, partition or PXE in combination with PVS?