This is the part I struggle with,
Apart from them them somehow intercepting the O2 sensor signal adding a correction and I suppose they cold intercept the injector circuit and apply a correction factor to spray more fuel. This would explain the instantaneous improvement that you get without the running in period and this would leave the base maps in tact and would mitigate the dealer / manufacturer seeing values outside of normal range.
With O2 switching are you surely not at risk of the ECU learning adjusting the maps if they "shift the O2 reading".
If they have found a way to circumvent a remap then I stand corrected.
I have no details about HT except for their public information.
So the following is just me "thinking out loud" based on my experience with programming in general:
BMS is a fuel/Ignition management computer used in several different vehicles, both cars and bikes.
In all of them the BMS needs to collect information from various sensors, and from the given information it decides how much fuel to squirt and the timing for ignition.
For all the vehicles, the sensors act the same way electrically speaking.
So it would be silly to develop separate software to separate vehicles as it does the same job, only different values.
Different vehicles have different needs, thus not all features are used for all vehicles.
This means the only sensible way of programming the computer would be to build up the software in tiny modules, where each module does a small job for one particular task, i.e one module reads temperature, one for throttle position etc.
Then you make a Main program that combines these modules and the Main program is different for each vehicle. The Main program is merely a boss calling upon the different modules as needed. This is the Management procedure, and it's quite small as it hardly does any calculations.
When a computer starts, any microprocessor of any brand, it starts at memory address 0.Then the built in clock increments the address-pointer, one at a time.
After the initial parts are called upon, there will at some point be an address pointer that points to the starting address in memory to the management procedure.
The management procedure does not need much space, so if you copy BMS procedure, modify it and put is at some available space and change the address pointer at startup, you are on your way.
The address pointer is a software value, but when BMW uppgrades their software, they change the modules only, not the starting point for the management, so if you change the address pointer to an alternative Management procedure, it will not be influenced by upgrades. As the adaption capability is kept, it would also be tempting to write an alternative way of handling the O2 values, as well as adjust the adaptive map for an emediat response. Since the management procedure makes all the calls you may then call the alternative O2 handler by simply calling it instead of the OEM procedure.
I'm not saying this is what HT does, but it is doable, though while it sound simple enough, it's a tedious job to search the BMS software and identify the various parts. If someone bothers to do this, they certainly have earned their money.
As for O2 shifting changing the Adaptive long term map:
Yes, that is the whole point. By giving modified feedback to the BMS, it still acts like the required fuel is what it takes to achieve AFR 14,7 +/- , as that's the feedback it gets. So the task for the AF-XIED is to read the O2 sensor and notice when the lower, selected AFR has been reached, and calculate the signals needed for AFR 14,7 and provide them to the BMS. Clever little bugger