I will try to provide some insight into the issue, complete speculation.
A typical CAN communicates like this, values not exact:
<Module Address 8 bits>+<Control 8 bits>+<Payload/Data 32bits>
The control will be read/write, CRC values, etc.
The module address will be a number assigned to each part (APIM, BCM, etc) on the network, similar to a static IP.
The payload is then broken into two parts:
<Register Address 16bits>+<Data Value 16bits>
The register address is a number that indexes which values to read/write from. Some examples would be:
0x00 Module Version/Info
0x01 Module Status
0x10 HVAC Status
0x11 Driver Temp
These register addresses are defined by each module maker and typically change from vendor to vendor with exception being 0x00 for version. So what you may have is
0x00 = 1 (Version)
0x10 = (Hvac status)
0x11 = (Driver Temp)
0x00 = 2 (version
0x30 = (HVAC status)
0x40 = (Driver Temp)
so that the address for the HVAC changes between APIMs.
It's completely arbitrary after the version info. So what a programmer for MFT would do is something like this:
if (readData(Version) == 1)
else if (readData(Version) == 2)
to select between versions. Then whenever the climate control section is used, it just uses getData(HVAC_STATUS) and that maps into the right register.
So whenever BSQUARE is responsible for "system integration", they read the data specs for each APIM and determine what version maps with what register address for the HVAC, etc. It's my opinion that they omitted the versions that are specific to the Focus in their latest build.
What's actually more likely is that instead of programming modular code, they just statically define each address when they use it, ie getData(0x10) for hvac and then they have to compiled a different set of code for each car (bad practice).
What seems somewhat obvious to me is that the earlier versions of MFT did something like this:
1: Read some data from the CAN
2: Wait until the full data is received
Then there would be an error in communication and it would be stuck at step 2, waiting for data it would never receive, until the system was reset instead of detecting and correcting the error. This aligns with most sporadic behaviors in these systems. With poor hardware design, the communication system will have glitches from time to time and it's important to design error correction into the modules.