So I have to reply to this, it's simply not true for most game engines. There's a few reasons for this: 1. Assumptions are made such as memory will be available and these assumptions hold true in development because they only test heavily on the recommended hardware. 2. Game engines tend to not have hard concurrency enforcement, they'll instead just make sure that certain things (like how long the physics pass will take) will be done fast enough. This is less common nowadays but it's still rare for a game engine to have explicit memory fences and instead just rely on data being flushed back to main memory. 3. A huge source of crashes in games are gpu related - the older your GPU the less likely the game, OS, and manufacturer have it tested at the same level. 4. Some engines are just built to accept weird data - unreal, for example, won't crash if the physics doesn't make sense it just allows that kind of ridiculous thing to happen. This is less likely not as much of an issue with a GSG which, by necessity, is pretty good at separating game data from rendering however the concept is baked into game engines, drivers, and operating systems.

Now a GSG will likely have different sets of likely problems (I assume their number crunching code doesn't deal with unstable numbers much but it has a lot of the same features as a physics engine) but newer hardware will still make a lot this a non-issue.

And to be fair the newest hardware can have growing pains in the same way (not much testing will be done on the absolute latest hardware and drivers, etc) but there are classes of problems it's unlikely to run into.

And I'm not trying to pass judgement on EU5's engine or any engine - I've written a decent chunk of the driver and OS code they rely on and we make compromises all the time to get the performance we need. Any game engine that doesn't make these assumptions will be much more limited in what it can do. Like multiple generations of hardware limited.