To my mind, using symbolic links is overkill. Given that many apps will set one of App$Dir or App$Path, would it not be easier to enumerate these for the applications that RiscPkg knows about? Admittedly, that also has its limitations.
Another solution is to simply have the user install the program as usual (via drag and drop) and then have the user drag the application to RiscPkg, thus telling RiscPkg the program's location on disc. I like this approach more as it allows the user the same control over their system as before (including deleting a program by simply deleting its directory).
Whatever way is finally decided upon, there would still be a need for a standard location for some things (modules and shared libraries spring to mind). However, we already have a standard location for modules (the !System folder) and I should think that a similar system for shared libraries would not be out of place.
Another thing that springs to mind is how to handle the situation where the user has changed program related files (eg the boot or run file). Perhaps some form of checksumming would be a solution. For example: The upgrade package contains a file with checksum information for each file in the previous version. RiscPkg then generates a checksum for the existing files on the user's computer and, if the differ, ask if they wish to upgrade that file (with the option of backing up their old one).
I'll shut up now, sorry if this is a bit long, got a bit carried away