Thanks to your research I located this within a few minutes. Fixing it takes a little more time.
PortalId is a very common issue with DotNetNuke modules and even with DotNetNuke itself. The trouble begins with a plain install of DotNetNuke which always works with PortalId of 0. When you have additional, deleted or expired pertals, things begin to behave differently. I spent weeks attempting to demonstrate how DotNetNuke was trying to write to the root of the hard drive instead of the root of the web application. They said it was not reproducable, only because it was only tested on a new install and only using portal 0. It was very reproducable with exisiting installations with multiple portals.
In fact, when AspDotNetStoreFront (ASPDNSF) was available for DotNetNuke the portalid used to change randomly which was extremely difficult to debug and caused all sorts of grief. It turns out that they were caching the PortalID upon initialization. This means that as long as the app stayed alive from web requests the program would work, but after an app shutdown, the next IIS request from any portal became the global PortalID used by the store. It is no wonder why that product was discontinued.
This issue is definately resoved but it requires a hotfix or new release.