Passing information to Chocolatey packages

We are developing various Chocolatey deployment packages for our AWS infrastructure. Some of these packages have no customization, they are simply standard packages for installing Chrome, Java, etc. Others, however (including packages for our proprietary data migration and automated testing platforms), require significant post-install customization. For example, our Chocolatey package installs Git for Windows (GfW) and then alters the Git config files so that the instance is preconfigured for a specific user. Our different Chocolatey packages have different types/levels of customization, but they all have this in common: they must be able to receive instance-specific information at deployment time that affects their operation.

While I know it is possible for PDQ Deploy to pass information via the package command line, I don’t think this is ideal. Instead, I think that using environment variables is a better way to go. This allows information to not only be passed at deploy-time but also at instance provisioning time. For example, when our AWS WorkSpaces are auto-provisioned, a GPO creates a bunch of permanent system environment vars that specify the user, client, project, etc. These are then ready by our GfW package in order to customize the Git config files. Using environment var may also allow us to leverage nested PDQ packages for a very efficient approach (as discussed below).

Here are my questions:

1. If a package step has PS script that sets temporary environment vars, are they accessible to scripts within Chocolatey packages that run in a subsequent step? I assume not.
2. If not, I assume that if we create permanent system vars in PS, those will be available. Please confirm. Note that when a system variable is set while a Command or Explorer window is open, that var is not available until the window is closed and reopened.
3. I assume that permanent user environment vars are not a good idea, unless they are truly intended for the PDQ Deploy User (which would be unusual since the Deploy User is typically not the same as the user who will be logging in to, for example, a workstation).
4. If #2 will work, then I’m thinking it would be good to encapsulate the setting of the environment vars as follows:
1. Have a single PDQ deployment package for the software
2. Have multiple PDQ “environment packages” that simply execute PS to create the environment vars with different values. Each environment package calls the corresponding deployment package as a nested package.
3. This approach seems practical because we won’t have more than a few environment packages

I am new to PDQ (we have both Inventory and Deploy) but am digging in deeply.

I would welcome any guidance and advice you can provide.