One more piece of science! 
Everybody knows that when we calculate "NextPoint = PreviousPoint + JumpPoint", we can also quickly calculate "PreviousPoint - JumpPoint" because the inversion is the same.
Therefore, if the inversion calculation takes a lot of time, this second point is cheap for us, and we can use it to improve K.
I updated Part #1: Added "SOTA+" method with K = 1.02.
Everybody knows that when we calculate "NextPoint = PreviousPoint + JumpPoint", we can also quickly calculate "PreviousPoint - JumpPoint" because the inversion is the same.
Therefore, if the inversion calculation takes a lot of time, this second point is cheap for us, and we can use it to improve K.
I updated Part #1: Added "SOTA+" method with K = 1.02.
This was something already known and smart guys here already used this knowledge for example in faster vanity searches and even for BSGS. arulbero posted this trick may years ago and it is also in the literature. I used the P + Q and P - Q same inverse speedup even for Python scripts, however there is one big problem here: if P - Q is a DP then this only marginally improves the collision probability lower and lower as DP value grows, because the walk does not continue from P - Q, it continues from P + Q. It is what I call a "weak DP". For low DPs it indeed brings what you call "K" down a lot, or more precisely, you get an increase in DP throughput with the same "K" if not a larger "K".
Do you remember a few months ago when you said you don't believe I reached a K of ~1.0 and it was most likely a bug in my code? Well, do you still believe this today?
