It doesn't even have to be fiendishly complicated. Each "time wave" is simply a different run of the simulation engine, with a differing set of inputs. The videos also explain how seemingly paradoxical situations, like units fighting alongside time-shifted selves are handled.
The JWARS simulation engines built by the US Department of Defense (in Smalltalk, BTW) could handle theater-wide simulations down to the individual soldier level at 10,000X speed, and this was implemented in Smalltalk many years ago. Handling a dozen or two dozen "time waves" in parallel shouldn't be too much of a burden.
I called it "fiendishly complicated" in this case because even if the code is simple when written out, the underlying mathematics is tricky. A programmer off the street couldn't just wander up and modify it meaningfully in the way that a programmer can hack on the Quake III engine without breaking it; the slightest change could cause massive bugs, if you're not maintaining the invariants. The word "fiend" is chosen carefully :)
The chronoporter is underspecified by the demo (which is not surprising and I do not mean as a criticism, buy the game to find out more). I can come up with several possibilities for how that works in game terms that match what we see in the demo, each with their own problems and benefits for the player.
What I'm talking about doesn't take any fancy mathematics. Earlier in this thread, someone else was talking about functional programming. You could do the same thing with OO, deterministic pseudo-random generators, and a few patterns like Action. All you have to do is support multiple time-shifted simulations in parallel, and you are mostly there. The complicated part is displaying "overlaps" but that is also not "fiendish." (And the game dynamics discussed in the videos would make that much easier.)
What is truly clever is the introduction of the propagating "Time Waves" in the first place! Once you have that insight, such a game becomes easier to envision implementing.
And you missed my point entirely about mathematics, I think. "Fancy math" here is not calculus or fancy topology or graph theory. "Fancy math" here is that you need to build a new fancy math that works with your temporal engine. You can't just sit down and hack shit out, or you will die under the combinatorial explosion of temporal possibilities. You need to build yourself a system of primitives that are time-safe under the temporal transformations you wish to run, and make sure that as you add actions they are also time-safe.
Or you will be crushed by the complexity. Standard OO will not help. You don't need "a functional language", but you damn well need functional style. You'll end up reinventing it even if you didn't know about it advance, with rigid, explicit control over side effects.
If you set out to implement this, you will find the standard Action/Command pattern to be not very helpful. This game has a much richer timeline than the usual Command pattern is designed to handle.
"All you have to do is support multiple time-shifted simulations in parallel, and you are mostly there."
No, that will be inadequate. That doesn't get you to backing up to arbitrary points in the timeline, and since the simulations are not independent, you're going to have a hell of a time expressing all the dependencies in standard OO.
(Note that you could easily do functional-style OO. No problem. But it's not just standard imperative OO, such as might work with Starcraft. This takes more.)
If you don't believe me, try implementing it in a model system. I can only handwave so hard here before you need code to see my point, unfortunately, but I am extremely confident that if you approach this with the standard grab-bag of imperative techniques, you will fail, hard.
The JWARS simulation engines built by the US Department of Defense (in Smalltalk, BTW) could handle theater-wide simulations down to the individual soldier level at 10,000X speed, and this was implemented in Smalltalk many years ago. Handling a dozen or two dozen "time waves" in parallel shouldn't be too much of a burden.