Hi AJ,
Well this is interesting and I *think* I understand the basic problem which is that the IPTC Stationery Pad will evaluate code replacements right away (interactively). What you want are multiple IPTC Stationery Pads (snapshots?) that you want to remain static for each day/job? All these share some common IPTC fields like Caption and Keywords that depend on the job. So rather than update all the IPTC Stationery Pads for each job, you refer these fields to user/client variables instead (via {usercustom1} etc), and since the User/Client Variables dialog does NOT evaluate code replacements right away you can put your code replacements there and only have to distribute a code replacement file (and possibly update the code replacement in User1 to \IndyKeys\ for example). But why not just stick with something generic like \CodeKeys\ so you don't have to setup the User/Client Variables dialog on each computer?
So first of all I'd say it is a "bug" or omission that the User/Client Variables dialog does NOT immediately evaluate code replacements, but if it did then your workflow would be broken. So we aren't gonna "fix this" unless we have another solution for you.
An option is to not "interactively" evaluate code replacements in the IPTC Stationery Pad. The end result would be the same (other than if you were to change code replacement files after closing the IPTC Stationery Pad). The problem is that some people use code replacements for a lot of text shortcuts, e.g. "\s\" for "Lucas Oil Stadium" and they expect that to happen throughout the program (although apparently it doesn't in some places like User/Client or for the contact sheet labels in the preferences).
Unfortunately if you type in {\IndyKeys\} then PM would interactively lookup the code for "IndyKeys" so we would have to disable the lookup if it were prefixed by the curly brace. Then we could have special logic for variables to see if it is a code replacement instead. This could get tricky.
I am curious why you have multiple IPTC Stationery Pads? Is it because of something like the Photographer/Title changing? If so, try using something like the camera serial number as part of a code. For example, if Joe Schmoe's camera serials are 1234 and 5678 then you can have codes with 2 replacements:
1234 Joe Schmoe Staff
5678 Joe Schmoe Staff
Then in the byline (photographer) field you put "\{serial}\", and for the title (position) you put "\{serial}#2\" etc. Then you just distribute the IPTC Stationery Pad and updated code replacement file to effectuate multiple SPAD versions that differ only on something that can be determined from the camera serial. Of course this means you better know all the serial numbers! We are working on a much more sophisticated way of doing this that would provide flexibility, clarity, and robustness for missing info but that is all I'm gonna say about that right now. Another option is to use the custom chars that most cameras allow you to setup for the filenames. E.g. ABC_1234.JPG and _ABC1234.JPG. You could use "\{fbas:0,4}\" and then have the code replacements for either sRGB or Adobe RGB files as:
ABC_ Joe Schmoe Staff
_ABC Joe Schmoe Staff
We are investigating a solution for you. The simplest is to not interactively evaluate code replacements in the IPTC Stationery Pad, maybe instead have an "Eval" option when holding down the Option key (Mac) like we do for the IPTC Info dialog. But we will surely get a bunch of "hell" about this for those who rely upon interactive code replacements.
HTH...
--dennis