Don't worry, I just bought all 3 packages, and I can replicate it too. And, as I suspected, I'm not so sure it has anything to do with GSX, at least not directly.
By enabling the Content error report in the sim, I noticed that, when loading the 777-300ER, on exiting the sim, I always get a notice there are errors in the ContentErrors.txt file. So I had a look at it, and it contained A TON of errors, all related to the 777.
The log stops after 1000 errors, so the last section is 999 but and many errors are very similar, some slightly annoying but not critical, like not finding some textures or some effects:
[error.6]
error=Failed to load visual effect "fx_PMDG777_beacon"
[error.7]
error=Texture PMDG_777_MISC_SPEC.DDS failed to load (FE_REQUEST_STATUS==13)
[error.8]
error=Texture PMDG_777_CABIN_METALLIC.DDS failed to load (FE_REQUEST_STATUS==13)
[error.9]
error=Texture PMDG_777_TAIL_SPEC.DDS failed to load (FE_REQUEST_STATUS==13)
Some more troubling, like a failure to load many gauges, due to the wrong version of Simconnect, for example:
[error.17]
error=C-style gauge failed to load: C:\Prepar3D v4\Gauges\PMDG_777X.dll, Gauge: CDU. Verify the correct version of SimConnect is installed.
There are about 80 errors like this, covering all gauges. However, Simconnect is not related to L: variables, so maybe we can ignore these as well.
But the bulk of the errors, which seems to be the most telling, are A LOT of issues that seems to be related to L: variables IDs, here's an example:
[error.111]
error=Gauge/Script Error
Type: Unknown
Name: Unknown
Error: PANELS lookup_var : SimVarGet Failed - Module_Var ID: "673".
There are 888 of them, (that's just because the log stops after 1000 errors), all with different ID numbers. However, most of these ID are repeated so, I ran a script over the error log that would remove all duplicate lines, and it came out with this result:
Error: PANELS lookup_var : SimVarGet Failed - Module_Var ID: "211".
Error: PANELS lookup_var : SimVarGet Failed - Module_Var ID: "211".
Error: PANELS lookup_var : SimVarGet Failed - Module_Var ID: "246".
Error: PANELS lookup_var : SimVarGet Failed - Module_Var ID: "280".
Error: PANELS lookup_var : SimVarGet Failed - Module_Var ID: "673".
Error: PANELS lookup_var : SimVarGet Failed - Module_Var ID: "674".
Error: PANELS lookup_var : SimVarGet Failed - Module_Var ID: "692".
Error: PANELS lookup_var : SimVarGet Failed - Module_Var ID: "693".
These are the unique IDs so, it seems, out of the many L: variables the VC use ( there are probably hundreds of them, at least one for each switch ), ONLY 7 failed to read, for some reason.
After my first test with GSX, to be sure these problems are not caused by a conflict with GSX or any other module, I disabled EVERYTHING
GSX, SODE, FSUIPC, Navigraph, up to a point I don't even had an "Addons" menu anymore. It's just P3D 4.5 HF3 and the 777.
And sure enough, even during the 2nd run, with *all* 3rd party modules disabled, resulted in the SAME errors as before: reports of the wrong version of Simconnect, and hundreds of errors related to reading the Variable IDs.
Now, a quick check on PMDG forums reading users reporting the same errors in the log, always invariably result in comments suggesting to just ignore them, those are only used by developers, and you should turn the Content error option off, and forget about it.
Well, first I find this quite shocking: those errors seems to indicate something is going on with the airplane and, before we do a new GSX release, I always keep it enabled and try my best to be sure I have ZERO errors in the log. When we have errors, they are usually minor, like a missing texture on a specific vehicle variation but, those in the 777 seems to be fairly serious and, specifically, mostly related to issues reading the Variables IDs.
Remember my explanation about the L: variables and their IDs ? That's seems to be the problem: somehow, the simulator is telling this airplane has issues reading L: variables, but that might not be a problem if you use the airplane alone, it only starts being a problem when something else use its own set of L: variables, like GSX, because when two programs that use L: variables are working together, it IS possible to end up with an ID conflict, unless both use the proper care to ensure this doesn't happen.
I think PMDG say you can ignore those errors because, traditionally, L: variables are used by airplanes and, since it's not possible to load two airplanes at the same time, every possible conflict that might happen, won't be visible anyway so, even if their code didn't account the chance of an ID conflict, it won't be a problem, and one can safely assume all IDs are usable when switching planes.
So, having made it clear the airplane has some issues with at least 7 L: Variables even when *nothing* else is installed, why this is happening only with the latest GSX Update, which SEEMS to indicate GSX is the cause ?
My guess is just because we added a bit more variables that will be used by 3rd party developers that interface with GSX, some of them has been added to help FsLabs with their upcoming Concorde, for example. It's possible that, considering the airplane DOES have issues with 7 variables, we just got lucky with previous GSX, because the number of variables used by GSX wasn't enough to start issuing conflicting IDs with the 777. It's difficult to know for sure, without knowing the simulator own strategy to reallocate and reuse IDs but, what I think is happening here is:
The 777 failed to read a variable. We don't know its name from the error log, only its ID so, assume is this one ( if it's not, I'm sure it's one of the other 6 )
Error: PANELS lookup_var : SimVarGet Failed - Module_Var ID: "211".
Here, it seems ( remember, I'm getting this WITHOUT GSX! ), the airplane code for some reason failed to read a variable with ID 211 so, it's likely the simulator would consider that ID "free to use". Let's assume for a moment this 211 number is the variable that causes the VC to change into the freighter version. The real name of the variable is "IsFreighter", BTW, the "custom_vis_IsFreighter_01" is only how ModelConverterX presents it visually.
Now assume we start GSX Deboarding, which at a certain point will ask the sim to register some L: variables used for, let's say, the Cargo loaders, those are the names we use:
FSDT_CargoLoaderGuides
FSDT_CargoLoaderBridge
FSDT_CargoLoaderPlatform
But as I've said before, we use variables by name only the first time when we register them, which means telling the sim we want to use a new custom variable, and the sim will return with an ID.
So, when GSX registers those variables, the simulator is likely considering the ID 211 to be available because when the airplane used it, it FAILED, so it gives ID 211 to GSX.
GSX cannot possibly know the 777 TRIED and FAILED to use that ID already, so it will trust the simulator that ID is in fact available, and as soon one of these animations starts, the 777 L: IsFreighter will be set too, because of the ID conflict initiated by the failure of the airplane to use it which, again, happens even with the simulator is completely clean of add-ons.
I'm fairly confident that, if PMDG can fix their code to remove ALL those 7 variable failures, the conflict with GSX will likely disappear.