Physics Engine linked to Framerate

[TheYellowArchitect]

The cardinal sin of gamedev.
I even knew about how bad it is to link framerate with physics, when I was writing the velocity system, yet I kept going because:
"Smash Bros runs at consistent 60 FPS, and surely Double Damnation can also run at consistent 60 FPS even in a shitty laptop"
The above was true at the time (2018), but I was so naive back then, thinking I had the feature-scale all figured out, when when I was still a newbie in programming (less than a year of programming!)

Every .velocity calculation ofc uses * Time.unscaledDeltaTime
So, where is the problem?
In my physics. Unity has no default acceleration values (it has velocity and force, but no acceleration), so I made my own, in order to recreate the DI (Directional Influence) feature from Smash Bros.
A blessing in disguise, as I implemented it for damage, but expanding it, I made Double Damnation have the unique and freeflow movement it is known for, today.
BUT. The acceleration increases per frame (this is why in speedruns, the lower framerate makes you faster, as less friction happens)
So, to solve this, I could go on acceleration (in-code, it is influenceX), and do * Time.unscaledDeltaTime
And indeed, it should become "framerate independent"

But since Time.unscaledDeltaTime is 0.0016 in 60 FPS, obviously the acceleration drops heavily, and the end result is not the same.
Hence, I must add a constant/hardcoded variable that when multiplied by 0.0016, returns the exact same values as current.

Why don't I do that?
Because it would take 1~3 days of playtesting, to get the exact value, and ensure the movement system will be the EXACT SAME as previous versions on 60 FPS (no movement regression, rip speedruns)
Its a boring process - I will do it eventually - but until then, I have my eyes on more important things.