Also on reading "deWiTTERS Game Loop", I disagree with fairly significant parts of it: the article goes all the way through without even mentioning v-sync, which is pretty strange. The goal of good game engine should be to draw a new frame at every v-sync interval. Picking 25 and 50 as example framerates are just about the worst examples. Picking 60 still wouldn't be perfect, because it doesn't address the problem that v-sync intervals come at different rates on different devices, depending on the display refresh rate. So that's quite a significant problematic area that it does not attempt to address.
Further the recommended solution proposes moving a fairly significant amount of logic in to the display function. In a good game engine, logic is a modifying operation and display is a read-only operation. The suggested solution sounds like it is really proposing three functions: logic, interpolate_logic, and display. So you call logic() at some fixed rate, then interpolate_logic() followed by display() at a higher rate.
To me this seems a kind of crazy way to design a game engine; it's a pretty big architectural change, and makes the assumption that it's good for performance if interpolate_logic() is cheaper than logic(). In fact if the game is GPU-bottlenecked, there's no point calling interpolate_logic() - you may as well just call the full logic() since it runs in parallel to the GPU and won't impact performance. And I'm convinced that even the use of interpolate_logic() will cause game logic problems far more serious than vanishingly small rounding errors with variable framerates, which will not cause any problems in a well-designed game with reasonable tolerances.
You can also simulate this method in the existing engine using techniques I've recommended previously: run expensive things like collision checks, for-each loops or nested loops on a timer, or at least every N ticks. Then you are effectively splitting your game logic in to expensive logic ticks (logic()) and cheap logic ticks (interpolate_logic()). This is just straightforwardly sensible game design and works well in a variable framerate engine as well, and can be done today without any extra engine options or rearchitecting.
On the contrary I'm of the opinion that the variable rate logic/display cycle is the best solution: it v-syncs nicely at different refresh rates, handles mid-range framerates reasonably well, and is simple to design and reason about (since logic updates and display updates come at the same rate). I think the only disadvantage is really low framerates can teleport objects through collisions, but most systems aren't that slow, and there is a minimum framerate of 10 FPS in the Construct 2 engine.