The proper technique is to use package configurations by either using an XML configuration file, or SQL Server based configurations. If using an XML configuration file, you can use Environment variables to specify the location of the XML config file, or heck, use an environment variable to specify an SSIS variable directly.
With that said, your SUBST technique has severe limitations, namely the fact that the new drive letter is VIRTUAL and like mapped network drives are a user session concept. Windows service accounts, much like the one that runs SQL Server Agent, has no knowledge of SUBST drives and as such will not be able to pick up files from those locations.
So, the moral? If you're always running packages through the GUI - SUBST/mapped drives will work. If you're running jobs through a service, like SQL Server Agent, they will not work as those drives don't technically exist -- they aren't physical drives.
There are many articles on this site and others talking about package configurations. Using the SUBST command may work in a pinch for some folks, but for better long-term portability and pre-setup, package configurations are the appropriate solution.
SQL Server MVP