I had a hack in the avatar controller where I was actually setting the avatar "keyframed" (much like typical static content in SL) to get it to actually stop when standing on a slope – otherwise it would slowly creep down the hill, even for very shallow slopes. I was finally able to get the avatar to stop on a hill without using the keyframe hack, so I pulled it out --> scripted pushes should now move the avatar when it has "stopped".

There is one minor issue, a little less likely to occur than before.

1) Place the following script into a prim
/////////default
{
touch_end(integer total_number)

timer()

}
/////////
2) Attach prim,
3) Touch prim, it will turn green, and you'll move 10m into the air
4) Wait 5 seconds, the prim will turn red
Observed: Avatar stays in the air
Expected: Avatar should fall when llStopMoveToTarget is called.

That's one issue. Related

1) Follow the previous repro, while standing on slopped ground
2) Once you get to stop 4, and you're suspended in air, tap the left arrow to rotate your avatar slightly.
3) Once rotated, you'll fall. A few moments after landing, touch the prim again
Observed: Avatar does not move
Expected: Avatar should again move 10m into the air

The problem was that when LSL actions (hover, moveto, buoyancy, etc) were created/deleted the code was only trying to wake up the objects that owned the scripts, in this case attachments which were not in the physics engine. I had to add logic to detect and walk up to the avatars to which they were attached and activate its RigidBody. There was some oddities in how Havok4 would sometimes not wake up the body even though we had tried to set it active, but I already had some hackery for getting around that problem, so I invoked it in more places (around the avatar) and that seemed to solve that weirdness.

Incidentally, note that llSetForce does work if the force is large (like 20 or so) but isn't working if the force is smaller (for my swim I was slow movement, with a force of 9.) Perhaps the reason you thought this bug was fixed was that you were only paying attention to large forces?

My script 'ramps up' the force it applies over time, to simulate acceleration but the new havok means i sit still while the forces ramp up until i break out of the lock. Then i'm suddenly (VERY suddenly) accelerating to about 45 meters per second until i slow down.

physics behave normally again while i'm moving but if at any point my speed falls below about 20m/Second, the damper kicks back in and I can't move again until i really amp-up the force again.

Strangely enough, this damper works on UN-assisted flight. I can use my assist to go up to 2km, well over the flight limit and then stop. If I then take off my assist, i will NOT fall! This damper seems to override even gravity! If i use my movement controls, I will return to normal, losing altitude even if i try to go up, but the moment I stop using the controls, i stop falling! I would expect to fall to the flight limit and then hover there.

I know it's a damper of some sort because while my flight assist is ramping up the force, my avatar will make subtle movements in the desired direction, and then stop again.

(quote of my problem as described elsewhere)
"All right, I'm having an issue with a phantom physical object. It's supposed to be bobbing up and down about 0.05m in either direction at a slow pace. It works, except that it inexplicably stops after a few seconds. If you click it, or even right click it, however, it resumes for a few more seconds, and then stops again. I checked its energy levels, and it's remaining at a constant 1.0 – not only that, it never changes, and it's a small object anyway, so it shouldn't be using up much energy. I'm using practically the exact same script I have in a larger object which works just fine indefinitely."

Same offer as Brandon, if you need me to send you a copy of my swim attachment then let me know.

Specifically, the testing I just did was to try to use my swim attachment. It works with avs in flying mode in order to float them to the surface of the water. I found that physics calls worked fine when swimming on the ground (ie. the flying character is sliding on the ground) but still don't work right when swimming in water (ie. hovering above ground at water level.)