That is incorrect assumption.

A program which does not do what it was designed to do has a bug... The .EXR file that is being accessed is the actual render that Poser is building... it -- by definition -- is a temporary file.

This should have nothing to do with the local profile other than by default PoserPro uses the "User Profile:AppData:Roaming: PoserPro" folder to store temp files by default.

When I changed my default runtime to a different location than the default  profile location, it moves -- so I have a folder called Runtimes which has multiple runtimes... I should be able to move the temp file location without moving my profile but it does not -- which makes this a bug rather than a feature...

In Windows when I move the swap file to a specific drive-- it moves... per the Poser documentation when I move the temp file it should move as well... but apparently FFRender64  does not do this and instead uses a hard coded environmental variable rather than reading the XML configuration or the poser.ini file . The hard code forces the file to be written to the OS user profile location rather than the "temp file" location as set in Poser. This defeats the purpose of  setting a "temp file" location.

I've tried rendering both with a "single thread" and a "separate thread" neither make a change... . Since disk read and write time are important for fast renders PoserPro renders much slower than it has to because I can't put those temp files on the SSD..

When app programmers take lazy short cuts [and this was a lazy short cut!] and don't think their design through you end up with sorry code and angry users who have to make "Rube Goldberg" solutions to correct the lazy programmers. Moving the user profile is a Goldberg solution but that looks like what I will have to do.