Well, the current state is so sensitive that you are literally not able to scale a cube to a desired size (especially when scaling down), because you are limited to a pixel density of your screen. It is so sensitive that moving a mouse cursor just one pixel on a 1920x1200 screen will scale the cube by a quite significant increment. I think that not being able to effectively scale a scene objects using a 3D manipulator fits into a definition of a bug.

In T53904#481641, @Campbell Barton (campbellbarton) wrote:

An issue with switching back to ortho on snapping is it will only happen at some orientations.

If turntable is used this is mainly an issue for top/bottom views - where you may snap to the top but look down from a different rotation.

The result would be snapping to the top would only switch to ortho if it matches pressing Numpad7.

We could switch to ortho but keep the view named "User Ortho".

if the tooltip states "Automatically switch between orthographic and perspective when changing _from_ top/front/side views" then the tooltip description may be wrong, because Auto Perspective does not only switch to ortho when entering the top/front/side views but it also switches back to perspective when initiating orbit to exit from top/front/side views. What I mean to say is that it works both ways, bot when entering top/front/side views and when exiting them.

Since 2.8 workflow release is supposed to include also reworked key map, I'd suggest some adjustments to to hotkey editor. In relation to this issue, first thing in order would probably be to add something into the user interface that implies hotkey order from top to bottom is relevant to hotkey functionality, because right now, probably almost no one knows about this. Once users are aware that the descending order of hotkeys is relevant to their functionality, they should have some basic UI elements to customize the order.

I do not understand how is this invalid: