Ah, okay, I think I understand the problem now. I thought the issue was the move_and_collide function was causing the player to slide on edges, with the normal issue being an additional (minor) issue.
I don't know why the KinematicBody2D is returning angled normals for surfaces at right angles. Perhaps it is as you said, where the behavior is to fix the issue where collisions at edges were not being returned. Another potential thing that could theoretically be causing the issue is very small corner overlaps, where the corner of the collision boxes intersect and so Godot doesn't know if the collision is going horizontal or vertical, so it returns a mixture of the two (just guessing though, I haven't looked at the code).
However, I think I know how you could solve the problem. If you send a raycast, either through code or from the Raycast2D node, in the direction that the player is moving towards, you could use the normal vector returned from the raycast collision to detect the angle instead of the result from the KinematicBody2D. Performance shouldn't be impacted so long as you are not sending too many raycasts at once, and last I knew the physics raycast doesn't have an issue with ninety degree angles.
One snag is that it might be difficult to find the position(s) to place the raycast origins depending on your game and the requirements. Looking at the pictures above, you might be able to get away with sending either a single raycast to the bottom corner of the collision box in the same direction the player is facing, or two raycasts with one going downwards on the vertical axis and another in the same direction the player is facing on the horizontal axis.
That said, there is probably a better way to get around it, but right off that is what I would do. I would also consider making a GitHub issue on the Godot repository for the strange normals returned by move_and_collide so it can be fixed.
Hopefully this helps!