Confirmed with a build from today.

Just like in 2.79 this is controlled by the User Preferences -> Interface -> "Auto Perspective" option. The only change is that this is now enabled by Default in 2.8

I believe this was fixed as part of 4c41f8e9ad3 and f40a88a4ba9

This can be easily observed with the default cube.

It still flipped to the top for me after an install with most recent git pull. Can anyone else still repro?

Might be a duplicate of T57620 (or at least heavily related?)

I seem to be able to repro here -- indeed it looks related to snapping.

Perhaps related/duplicate of T57485

Confirmed here as well. Looks like it's the same cause as T57312

Rebuilt from scratch after my previous comment to know for sure. But I can repro OP's issue when using a Debug build (compiled from source) which allows the assert to hit. I was also unsuccessful in creating a repro .blend; the act of saving and then re-loading the .blend seems to fix the issue. Perhaps the mesh loop/normal data is not being updated correctly after one of the operators but is being updated on .blend load?

Some things I've noticed that probably fall into this category of fixups:

That card may not be fully OpenGL 3.3 compliant according to its specs: https://www.geforce.com/hardware/desktop-gpus/geforce-gt-120/specifications

Duplicate of T56011 probably

Here's a gif showing the flicker in case a repro is hard to see -- happens on my 2 Win10 machines, 1 with nVidia Quadro and 1 with AMD fire pro

The spec sheet for that graphics card only lists OpenGL 2.1 (which is below the minimum that 2.8 requires which is 3.3): https://www.geforce.com/hardware/desktop-gpus/geforce-9500-gt/specifications

The option would be system wide, and called something like "Remember previous operator settings: True/False". You would Ctrl+B and confirm whatever you want. After that, each time you Ctrl+B you get the values that were confirmed prior. No additional button required, just Ctrl+b, Ctrl+b, Ctrl+b etc. etc. It's system wide since this would work with the Inset operator too, and probably others.

Yup, same crash with using the, very slow, opengl32.dll

I'm away from my laptop, however, I can reproduce the problem on my office desktop as well -- same crash using the vc14 builds. System is Win10, nVidia Quadro 600 this time.

Ok, I tried again, here's some more interesting information: