Both actually.
From my own testing and general information I could gather, the game can slightly bug out here and there due to the CPU type option causing a weird install for example.
Things like the installer miss matching the UFO2P.exe with a renamed TACP4.exe and even if you mitigate that by copying the XCOM3 folder form the CD over, renaming it to XCOMA, then doing a full install on top of it and then again copying the XCOM3 content (except for the options.dat file this time) over, to make sure all files are as they are meant to be without some weird install alterations, things might still not work the way they should using the "auto" cputype.
One thing I've observed is the default (fall back) AI breaking for example. (like, when the Learning AI is already not working the basic default AI will take over)
UFOs just circling around the Cityscape without shooting or depositing aliens into the city. Hostile units during tactical missions just running around but never using their weapons.
Then there are things like the market sort of breaking around mid/end game, with nothing being purchasable anymore, no more soldiers to recruit and so on.
Also, though I still have to do some testing on this, this might also be one of the reasons for the Learning AI not working when using an image file instead of the original CD, like in the digital distributions of the game from GoG or Steam.
The game does prioritize files that are installed over the files of the CD (i.e. if you run the original UK version but copy over the SMK video files of the German version, those will be played instead over the English SMK files of the CD) and by that logic it might also be able to bypass the CD checks for the Learning AI if it reads the files from the install folder instead.
But with the weird installation issue and CPU checks of the game, that might already cause some weird hiccups that just break the AI instantly, as it is very fragile to begin with due to the whole game being super rushed.
The game performs CPU checks at 2 different places, one being during the install, where then it decides to alter several game files if detects the CPU to be 80468 instead of Pentium, causing possible miss matches of the UFO and TAC files and maybe other slight alterations to other files.
The other CPU check I do not know where it is performed, but it might affect the game in similar ways and prevent it from performing the way it would if it were to detect the CPU to be a Pentium.
In general the 486 files of the game were optimized after the initial Pentium game files were created and seeing how the game was incredibly rushed at its final stages, it might be likely that the watering down of instructions and functions of those files might be so rushed that they didn't even have time to proper test things when they were done, leading to those weird issues I've observed.
Then of course having the possibility to run the game with near perfect performance using a "pentium_fast" cputype just like it is possible to do at least that using the "auto" type.
#Apocalypse: cycles=60000 (windowed) ; cycles=100000 (fullscreen) ; cputype=auto ; core=dynamic
Are the DOSBox settings needed to make the game run almost perfectly with what DOSBox has to offer currently (at 1280x960 and 1920x1440 resolution, openglnb), along with that the [mixer] setting has to have the prebuffer and blocksize increased to the maximum allowed value "8192", to avoid sound popping, and the sound card chosen in the Setup of the game has to be "SoundBlaster Pro".
(luckily the sound delay is so little it doesn't bother you during the game but instead allows a smooth sound output, regardless if turn based or real time mode)
Here are 2 short videos that show how fluent the game can run with those settings:
https://www.youtube.com/watch?v=D5bWeRkttJg&t=2m13s
https://www.youtube.com/watch?v=KFFL4bgrNf4&t=2m51s
Those settings almost fully mitigate slow downs caused by too many explosions at once or when you managed to fill up several levels with smoke or stun grenades, or at least reduces them to an amount where the game is still perfectly playable and the slight slowdowns won't bother you.
Compared to that, with the "pentium_slow" cputype the game just runs too slow overall, with the same settings as above but only 20000 to 40000 cycles possible without it turning into a sound popping and super stuttery mess, any time there is an explosion the game slows down or shortly freezes the actions to process what is going to happen next. Any time option faster than "normal" causes a stuttery fast forward where it almost looks like everyone is sort of teleporting 2-3 tiles at once.
(I tried lots of different settings with "pentium_slow" but unlike my optimized "auto" settings, they are nowhere near the amazing almost perfect performance)
My hope is that with a "pentium_fast" option, the weird buggy game behaviour can be fully avoided while allowing the game to be played with as good of a performance as in those videos I linked.
That way during the CPU checks the game will always detect a Pentium CPU.
There isn't too much or any information about what instruction sets the Pentium game files make use of, but seeing as how several issues can occur mid/late game using the "auto" setting, I assume it does take advantage of some of them, as the game has been initially designed to be played on Pentium CPUs with hasted backwards compatibility to 486 CPUs.
And maybe along with that the Learning AI can even be made working on the digital distributions of the game, which also come with horrible wonky installs. (The GoG Galaxy install has miss matched UFO2P and TAC2P files, the Steam version is also about as screwed up, both use the original 1.0 UK Version)
I also have like only very basic knowledge about programming and how DOSBox itself works, but judging from that CPU Type Forum post, the "loose page" vs "tight page" might be the thing that holds the "pentium_slow" option behind in terms of performance?
Anyway, if there are more questions I'll gladly try and answer them for you.
Thanks so far for your interest 😁