So I figured it out and it kind of happened in an instant of mad science magic so I don't know how to properly document it so I'll write my thoughts down as quickly as possible.
It was honestly dumb luck that I started multiplying and dividing things and I made this new variable called "move_multiplier" which I divided by the equation used to calculate velocity:

velocity = velocity.linear_interpolate(direction * speed, accel * delta * move_multiplier) / 1.0025

The "1.0025" is what I like to call, "the slog constant" or basically how dampened the movement is for the player. If divided by a small number under 1, it will accelerate the player in a way I do not like while they are in motion. If they are in motion though, this constant makes it so that they will start moving and then reach a max and then stop. I decided to add the move_multiplier first as a way to slow the player when they stopped moving as you suggested but then I gave it a less than 1 value and saw that it added what I can only describe as a "slippery factor" where they would glide off of surfaces and then stop. The movement was a bit too tight than I would have liked it to be and there was no momentum so I thought this was a cool addition. The problem was that this was only affective on floors so what I did was make another variable (which I already had for other reasons but decided to repurpose) called IsAirborne. IsAirborne is a boolean that uses is_on_floor as it's indicator. So what I did was this:

(This is in the _physics_process(delta) function by the way)

if IsAirborne == true:

move_multiplier -= delta

move_multiplier = clamp(move_multiplier, .05 ,.8)

if IsAirborne == false:

move_multiplier += delta

move_multiplier = clamp(move_multiplier, .05 ,.8)

Delta basically keeps account the time passed since the condition is met so the more a player is airborne they will experience a clamp (min and max range) that reduces the value move_multiplier (where small values make the movement more slippery) and in reverse, if the player was not airborne, they would experience less slippery, more grounded movement. I like to think about these values as the "grounded range" that controls how tight the movement is, where move_multiplier is made to go toward .05 (very slippery) when airborne and then on the ground will go to .8 (very tight but some slip for general movement consistency).

I probably inadvertently recreated something someone else already did and it broke part of my auto-bhop functionality but I'll plan to see if I can fix it somehow but right now I'm satisfied I concocted this weird but workable movement system.

I'll go more in depth if you want but I already rambled a lot and I frankly don't know how I even figured it out.

First of all, I got to say I really liked your game. There is another rocket jumping game that some guy is making in Unity that I am following so hopefully that will go somewhere...

I would be really glad to see your code and maybe I can give you a sneak peak as to what I already have because since I've originally posted here I've made a ton of progress but I wasn't going to show it until later when it was really refined to my liking. 

As for the Godot thing, it does suck that your project broke and I might heed your advice and transfer the project to an LTC version of Godot so that it can last but it might be too late for that or maybe it's still possible, who knows...? To hear you actually went ahead and programmed your own mini-engine is fascinating and sounds really difficult to make sure everything in the 3D world works.

One problem though is that I don't use Discord for personal reasons so it will have to be somewhere else. I have a Revolt (Discord-like) but if maybe we can talk here or find some other platform.

I hope I am not late in replying to this but anything helps.