So this is gonna be long winded but I found the problem and a easy way to repo it under build 1146.2.
I see Dimitris or others devs already found the problem as well though or part of it because 1147.2 does indeed appear to solve the only way I could find to repo it, and I went on a bit of deep dive to do so.
So in short version was\is that it stems from the fact once you touched (or something else touched) a aircraft in the scenario and enabled terrain following mode (even if you checked and unchecked the box while paused), it would never ever really go away, even if you landed and returned to the air etc. Short of deleting the unit you were stuck with it in a way because DesiredAltitude_TerrainFollowing got set during the save serialization process even when Terrain Following was disabled. Even though you would turn it off, and after a little clicking around it would indeed turn off while you played, or appear too it was still there. Also stored in the save were all the values to tell the game not to use TF. However during save the DesiredAltitude_TerrainFollowing entry would get saved, and be set to it's last value that it was at before TF was disabled. I presume it gets serialzied when non-null. That was a problem because on de-serialization (ie loading the save) it would get set again, and for reasons still fuzzy to me during that process the desired altitude would get reset to the desiredAlititude_Terrainfollowing one even if TF was\is disabled.
Now this isn't news to the developers cause that last part of it (using it upon reload even though the other setting say it's off) appears to be fixed in build 1147.2, but the DesiredAltitude_TerrainFollowing getting put into the save even when it's disabled in the first place is still around in 1147.2.
The story behind finding it:
I finally find the save I knew I had somewhere still, a save (originally from b1142), of a early version of Bodo Express where upon load you can see it happening to two groups of aircraft, right as it loads.I know when I saved this file these two groups were chilling on their course and manually set to 36k alt, I also know they didn't give me problems at that time. I happen to be saving this seconds before a posture change happening again that I'd already reset from and I was debugging that at the time, I was quite aware of everything going on with all my units. So I *think it's a snapshot in time from when my aircraft were not having the issue (but were only on re-load), so I think it has to do with 'what got saved'. The groups in question particularly "Flight Shadow50" group (consisting of samhold #5 and samhold #6) I know 100% never had terrain following enabled by me. They took off, I had them fly north-east a bit and then directly east way-point which they still have not finished at the point of the save. They were set to 36k manual and loiter and were left alone as I went on to focus on other things at the time. I recalled all being well at the point of the save and after and it was, till reload later on as I recall and see again now.
Weird so I'm thinking something in the save is triggering an override even though the correct starting values are there.
So I go on an adventure to pick apart the save, well that's not as simple as it used to be.
Anyway I eventually find all the settings in the save look good on the group, so on to the aircraft themselves, everything TF related is off, all the altitudes look good, the way-points aren't telling it anything screwy, but I notice the Desired_TerrainFollowing entry has 200ft set. Well that matches the ~2000 ft I keep seeing since they're location is ~1800ft AGL. So clearly this guy is the likely issue. How do units that don't have this problem look by comparison? Sure enough no DesiredAltitude_TerrainFollowing setting even stored. Lets skip ahead.
Anyway now armed with that information the repo is pretty easy (the key is knowing reloading a save is a must in the first place to really see the problem).
Repo:
Loadup any recent build prior to 1147.2.
Step 1: Load up a simple uncluttered scenario where you know there's been some fresh aircraft added to the airbase and not touched yet, launch 2 as a group, put them at manual 36k, let them get there, and save, call it blablabla_before.scen. It can be any scenario really but looking though 300k of xml is easier than 40mb in my case.
Step 2: Reload the file you just saved, let it run a few seconds. No problems will be seen with said aircraft\group.
Step 3: Turn on TF on said pair of aircraft (it doesn't have to be a group btw happens on singles as well) and min altitude or whatever alt you want if you're not over the ocean, wait a few seconds not the movement. Save as blablabla_afterTF.scen
Step 4: Now set everything back to original manual 36k with TF turned off (you can even do it manually to each of them, or ungroup them and do it...doesn't matter), wait a few seconds for them to do the change and get back to 36k. Save, call it blablabla_ResetToNormal.scen
Step 5: Let it play for a few seconds more, note your aircraft are doing fine. Now reload blablabla_ResetToNormal.scen
Your aircraft will act like they did when you saved blablabla_afterTF. You don't even need to hit play just f2 on them to see the desired altitude is wrong.
Optional which avg user can't do: look at resulting xml of each of those 3 saves.
Optional step 6. Loadup build 1147.2 and load up blablabla_ResetToNormal. NOW your aircraft should be ignoring the DesiredAltitude_TerrainFollowing even though it's stored in the save, and your aircraft behave as you would expect.
Now, as wrap up this novel, I still for the life me don't know how TF ever originally got set on some of the aircraft in the real scenarios I was playing, but it could have been an earlier bug fixed months ago but residue lingering in saves, could have been left-over from scene author doing testing and having thought they reset everything to a clean state (and they would be correct in assuming that), or that guy between the keyboard and the chair's memory. In any case I think 1147.2 fixes the core of the issue, which was desired altitude getting set to the DA_TF if it existed upon load. Though it may be worth looking at excluding that entry from serialization entirely when TF is not otherwise activated, but there may be side-effects or considerations to that for which I wouldn't know.
Side note - I noticed <flight>guidhere</flight> seemed to go away for the flight leader when doing save comparisons between 1142, and same file loaded and immediately saved under 1146.2, I assumed that wasn't part of the problem and just churn.
attached: scenes at various states. A good test for confirming 1147.2 fixes the problem is load up the bodo express file, select 'flight shadow50' group in the bottom left, hit f2, if it shows you 36k as desired altitude it's fix confirmation. If you shows you ~1985 like it will under 1147.1 or problem still exists. Only bothered attaching for some samples to have for regression testing in the future.