Alright, small update to the behaviour. Again, so sorry about the wait. Had I known I'd be this busy I'd have waited until I could provide more regular updates.
Changes:
Air drag now works
Simulate Jump now works again
Can now specify an angle threshold for when the downhill slope factor will have an effect.
Issue with 45 degree slopes locking controls fixed
KZR:
Found that slope issue you were talking about! When the object stops moving on a slope (assumed to be because it's too steep) the engine locks horizontal controls for a fraction of a second while the slope factor kicks in and pushes the player downhill a bit. Generally this is a good thing, since you don't want the player on a slope they can't walk up just pushing against it, but with slope factor disabled (which I'm assuming is what you did?) and when on a 45 degree slope (also assuming you did that) it triggers the lock, doesn't push the player down, and just sits there counting down the horizontal control lock and repeatedly triggering it again when it hits 0.
The threshold for the angle is 45 (non-inclusive), but with swapping between radians and degrees being a little unexact it's counting 45.0000012522 as being above 45. Which it is. I've changed it so it's a parameter defaulting to 46: FallingAngleThreshold. If the slope is shallower than that, falling off should not trigger. Should fix the issue as it currently is, as well as allowing some fine-tuning if it still presents a problem.
There are a couple obvious issues still present that I really need to work on (including tilemaps, which I will get to, I promise!), but if I'm honest I'd still expect things to be a little slow on my end for a bit longer yet. Please keep letting me know if there are any issues, and I'll try to solve them as soon as I can!
Also, regarding rotation and the Set Angle property, I've had a quick go at it and ran into issues reliably moving things around so as not to clip a non-square bounding box into terrain or off a slope it should be sticking to. It isn't ideal, but as a workaround I'd recommend keeping the collision poly for the main object square, and overlapping another object with a non-square poly if you need one for other collisions.
I'm getting to the point where my inexperience with some of this is showing, so if it comes to it, please bear with me as I try to refactor things to make future changes more feasible.