Graydon wrote:Now.. using this example, I'm curious as to how anything gameplay related whatsoever could possibly have changed
Off the top of my head? Improper memory management/sloppy/imprecise coding (in the original code base) using something like offsets to define location in memory of variables.
Hypothetical example: The TFL coders, being the clever people they were, realized that reading the overhead map from the plugin everytime someone hits <TAB> would really slow the game down, so they created an array to store the overhead map so when Myth loads the plugin it copies the overhead map into memory. Although most maps were only 128x128 in size, they decided it would be good to plan ahead so they thought 384x384pixels in size would be big enough. In fact, even though they knew the interface code itself was only going to display maps 384x384 or smaller, being fond of binary numbers - and just because they could - they made it even larger and made the array large enough to hold a 1024x1024map. . So far so good.
Ok, Now skip ahead a year and I am a Myth2 developer and I have some new map related flags (indicators) I need to read and store when the plugin is loaded.
Hypothetical things like 'Can this map be set on fire?', 'Does the map have a ceiling?', things like that. I decide it makes sense to store that info RIGHT after the map array, but I am lazy or burnt from too many nights of late night coding so instead of defining another array or creating new variables I know that there is a lot of 'wasted' memory 'slots' in the overhead map array not being used so I define the variable to use (overlay) some of the unused memory at the end of that map array table.
Now fast forward 10 years and I am a developer who sees the 348 restriction in the CODE that loads and the code that displays the overhead map and I notice that the map array table is lots bigger than 384, so I bump the limits in the loading and display of the overhead map up to 1024x1024.
So now, we have two seperate pieces of information potentially occupying the same position in memory - the map color values, and some map attributes. WHICH information is actually stored there or is used bby the program depends on the order it was loaded, but there will be two very different sections of code looking at that same piece of memory and thinking it is something unique - which it is not. . In this hypothetical example, the consequences aren't that severe - and small maps might still work fine, but if the program loads the map attributes FIRST then loads a 1024x1024 map (filling the entire array) it will overwrite the map indicator variables with color info about the map. In this case that might mean that all sand-rock maps might now be able to be set on fire, grassy maps might not burn, or 'random' pixels on the overhead might display the wrong color, etc. But the results won't be predictable because SOME rock maps will burn, some won't, same for other maps. That's all relatively harmless (though not a good thing) but this same KIND of error could also cause crashing bugs.
I realize this probably doesn't at all relate to how Myth/MythSB were coded, and MAY not even be possible depending on the programming language M2 is written in - but it's an example of the KIND of unexpected gameplay effect that could result from a small 'unrelated' change in an unrelated section of the program (the interface).
Many of the features added are optional stuff that can only be activated by the mapmaker who chooses to use it. The stuff that has broken gameplay have been changes that try to fix some gameplay bugs that has been around since the game came out. I still miss the bug from build 305. 
It would have been a nice feature for certain units. It made missile units not turn around to attack. So imagine a unit that didn't have to turn around to attack.