The PSF is useful for setting environment variables that are read in no matter where parametric.exe is called from (like windchill), but when you change license configurations the file is overwritten and your changes are lost, and the changes have to exist in every different PSF that is used. Instead of all that, add a separate config file (xml, perhaps?) that will be read in by parametric.exe, no matter which PSF is used. For full implementation, allow the user to specify a config file other than the default in the command line.
Basically, it's just a second PSF being read in, but it is independent of PSF selection and does not get overwritten by a reconfiguration.
There is a "USER" section in the PSF files that is not supposed to be overwritten when running reconfigure.exe, but unfortunately is overwritten. I believe it wasn't in the past, but I don't have an old install to test it. I thought the intent of the "USER" section was to allow the users to run the reconfigure.exe command and keep their changes intact. I see the "USER" section being overwritten as a bug (or at least a change in intended functionality).
You can always create a simple script to append your companies "USER" section to the end of the .psf files.
I get where you're coming from, and I think it could have some good use cases.
We developed a bit of a work around for our PSF files. We have our PSF's pushed from the server with our config.pro/sup and other various settings files.
However we ran into an issue that we allow multiple builds of Creo and now with Common files having a build folder in 2.0 it means we have to worry about the Creo Build for each individual PC. Our users don't change the PSF's, and often times nor would we want them to change them.
To get around this issue we have a locally saved "header" with info for that specific PC, and then we have our server copy "footer" of all the bottom part. When the user launches our scripts it merges the local and server files together and creates all the PSF's. It would be great if we didn't have to "trick" it and use a single config file. My next plan to build a new startup was to create a single PSF on the fly based on user selections in a graphical UI. Dropping in the appropriate data as needed so there remains only a single PSF for the system to see.