Secondly, if a game is too slow to play, large choppy movements wont really solve the problem that well: Consider an fps where you turn right,a dn after half a second you get to see where your targeting: Its even less impossible to target than it would be were it running slowly such that a great amount of time would pass to turn around (Not that i would suffer playing like that either).
Sacrafice to the collision-queried positions in larger movements is also a trouble: {Er...by that i mean say you had a 2d blitz game, using ImagesCollide, where images might end up moving too fastly through each other if the frame rate was dropping}:
Both of these scenarios are moot, because a simple addition to your code (such as Sacrafice to the collision-queried positions in larger movements is also a trouble: {Er...by that i mean say you had a 2d blitz game, using ImagesCollide, where images might end up moving too fastly through each other if the frame rate was dropping}:
If FL\SpeedFactor# > 2.0 Then FL\SpeedFactor# = 2.0) would prevent both of those scenarios from occuring. Sure, the program will run slower than intended, BUT if the PC is too slow to run the program, then it's TOO SLOW. Delta-time isn't intended to make a slow PC run faster, it's intended to attempt to make a program run more smoothly. But alas, if it's not possible, then it's not possible.
Use delta-time for what it's intended to be used as, not as some kind of speed enhancement code.
but i never take frames out of logic while letting rendering work at full pace:
I don't know why you stated this. Delta-timing doesn't do this.