I am pretty sure this works as intended. 2.80 has "Release Confirms" enabled by default in Preferences. Enable it in 2.79 and you have the same behavior. Or vice versa, if you disable "Release Confirms" you get the behevior you seem to be lookin for. Besides, you can always cancel the Action by pressing Escape. So, I don't see a downgrade really.

Sounds more like a duplicate of this one: https://developer.blender.org/T57770
And that has been resolved.
Please check if it still happens with latest builds.

Yes, I can reproduce this bug as well.
However, it seems kind of random. It is not always the same marker, which deletion causes a crash. Sometimes it is the marker that is already selected when you open the blendfile from BlenderBugReport.zip, sometimes I have to keep deleting and selecting markers until I get a crash. The crash can happen with markers from both, Camera and Object.
It is probably related to this bug, which was already reported a while ago: https://developer.blender.org/T58773

I can reproduce this as well. I open the tracking_test.blend file from above, select any Marker, hit X to delete: -> CRASH.
Here's the log from --debug-all: http://pasteall.org/1402918

I am not quite sure if this is really related, but since then I am getting a CMake Error:

This has been fixed, yes.
This one however is still open: https://developer.blender.org/D4020
:)

This sounds very much like an issue with colormanagement. In 2.80 the default view transform is Filmic. In order to display movie clips correctly the correct mapping has to be applied first. This happens during playback. So once the clip has been played back once, the movie was "converted" internally to the correct view transform. That's why playback is realtime the second time you play it.
You can also set View Transform in Color Management panel from "Filmic" to "Default". That should give you better playback performance right from the first play of the movie.
(Sidenote: "Default" is really not an adequate term anymore, since it isn't even the default setting! :)

My colleague just tested this on Windows10 with the most recent Blender 2.80 build.
While it does prefetch the footage, it does act a bit weird. The interface seems to freeze until the prefetching is done. Unlike in your case however the footage is in memory after prefetching is finished.
Even though the GUI is a bit unresponsive, we could still press the little X in the prefetching progress bar to cancel it. It works pretty much the same as on my Linux system. Our systems are quite good though (32GB, Hexacore). 4GB of system memory is far from ideal for motion tracking, so poor system performance might play a role in your case. Still, I can't really see a bug here.
However, responsiveness when caching movie files could definitely be improved. When prefetching image sequences the interface stays fully repsonsive here, and the way the progress bar is reporting the prefetching progress is more realtime and repsonive as well.
When 2.8 is more stable and there is a bit more time for polishing this might be something to look at, @Sergey Sharybin (sergey)?

Ah, good one. Maybe instead of Detect Features? This is not used so often...

Yeah, happens here as well (Linux, GTX980, Blender.280 ebfea8c).

Interesting. Would be nice if some other windows user could test this. At the very least I'll have my colleagues in the office test this on monday.

Removing shortcuts is fine, but I was looking for the Flip Normals command as well today and was surprised not to find it in neither Context nor Faces Menu. I think it's quite a common operation to be used in Edit Mode and I don't see a reason not to include it in Context or Faces Menu. What do you think about it, @William Reynish (billreynish)?

How much RAM do you have, and what's set in your User Preferences, in System>General>Memory Cache Limit? If you prefetch and watch your System's memory consumption, is your RAM filling up or not?

I don't see a bug here. It's true, Blender does become unresponsive for a moment, but that's just due to the prefetching of the movie file. Prefetching image sequences works smoother. At least on my system (Linux64bit) I cannot see a difference in prefetching between 2.80 and 2.79.

@Sean Kennedy (hype) You have probably tracked in way more programs than me, but at least in the handful of tracking programs I tried none of them had the same approach to super accurate supervised tracking like we have eihter. I think in Blender the single marker plays a more important role by itself than elsewhere, so I think it's fine if UI reflects that.

Ah indeed. Can only reproduce with mask points though as well, not with tracking markers.

I tried it with several configurations, but couldn't reproduce it. Toolshelf and Sidebar expanded or collapsed, floating panel expaneded or collapsed, fullscreen or not - I could not reproduce this bug in any case. I am on Linux though. Might be a Windows bug?

I am not sure about merging the track settings to just one panel. It would be a regression to 2.79, where we have those settings separated.

Flip is one of the most used buttons in the colorramp node, at least for me, so having that go into a submenu is not really an ideal solution.
Why not move the menu or icon for the even distribution thing between the two sliders below the actual colorramp? Those sliders are quite big, especially the position slider is larger than it really needs to be.

I have changed some of the shortcuts.
The Alt key is now being avoided, because on a Mac it is not as comfortable to reach as the shift-key.
So:
Tracking Pie: 'E'
Setup Marker: 'Shift + E'
Setup Display: 'Shift + D'
Setup Tracking Scene: 'Shift + W'
Solve: 'Shift + S'
I find these very comfortable to reach and execute.
Compared to the clip editor hotkeys in 2.79 we would sacrifice Shift+D, which was used for the 'Disable Marker' Hotkey.
However, that operator is in the Tracking Pies at the bottom, very easy to reach.
And the 'Show Disabled Markers' toggle is now at the bottom of the Setup Display Pie, so in the same position, hence very easy to remember.
Following that logic I think we can also remove the hotkey Alt+D, currently used for the "Show Disabled Markers" toggle.
And I would vote for having the tracking pies enabled by default.

Thanks a lot for the feedback!
I agree about the lacking feedback for a toggle in a pie menu possibly being an issue. However, I would like to keep most of them because it makes the workflow so much faster. And they still can be used in a gesture style interaction, contrary to some other pie menues from the community, where there are multiple entries pre pie-slot, something I consider opposite to the idea behind our pie menu implementation. But I'll have a look again and see if some can be replaced.
About hotkeys, well, the left side is pretty crowded. Q, W, A, S, R, D, X, C are all taken. I find combinations of Shift and E, W, S still very easy and comfortable to execute with the left hand. I was about to say the same about Alt+E as well, but I am typing this reply on my macbook, and there the Alt key is in a less comfy place. So I'll have a look at the keys again. :)

But why not simply use the available space in the header?
The timeline will usually be quite thin or even completely collapased to the header, like for example in the Animation, Motion Tracking and Video Editing workspaces.
So users would have to make the sidebar taller in order to use it.
Usually the timeline will be quite long, there is plenty of space left and right of the playback controls.
Why not put those menus there?

Yes, I can confirm that.

That could be a solution, yes.
I still don't see the need to change the current behavior though.
If you delete in Edit Mode it also brings up a menu that works the same way: If you move the mouse away, nothing happenes. Sure, you have some more options there, but the principle is the same. So I don't see why that would have to be different. Especially because in 3d View deleting an object can have much bigger implications, performance and dependency wise, than in other editors.

The same conversation popped up few years ago, and I still strongly disagree, especially for deleting things.
For dialogs where the action already happend, like remove doubles, simply showing a message is fine. But I believe this case is already solved, just like you mentioned.
However, I would be strongly against deleting stuff without confirmation. Blender has always been a rather hotkey oriented tool. And it is just too easy to hit X or Delete etc. by accident. Sure, in small scenes you could hit Undo, but in really heavy scenes, where selecting or even deleting can take a couple of seconds or, even worse, could cause a crash, that would be unacceptable.
Most operators in Blender can be cancelled before they where executed, and I love that. Especially delete should also work that way.

Yeah, I see the point. So what do you think should happen with the Toolshelf in the clip editor? Because that is currently very different, conceptually, from the toolshelf in the 3d view.

@Campbell Barton (campbellbarton) What is the reason the mask toolbar has been removed? It certainly does not make masking easier, and it also does not really improve the UI?

I cannot confirm that. For me proxies do work in the 3d view, at least in 2.79 (2.8 seems to have issues). The proxies generated with the clip editor, that is.
The proxies that you generate with the VSE are a different thing and serve a different purpose, as far as I know.
Could it be that you are trying to load proxies from the VSE?

Well, that is true. The problem does remain though, even when picking colors that are within 0..1 range.
Let's say for example, you have 2 meshlights, but with 2 different materials. If you want to pick the emission color from meshlight A to meshlight B form the viewport, you will not get the same color, because the color picker is not picking the reference but the color that was generated by the Display transform.

Updated the Diff again. Now there is only 1 Display menu, that is also visible when in mask mode.

Updated Diff so it applies to current 2.8

This sounds more like an issue with step 9 in your list: zooming out too far.
If you go to View Menu and select "View all", or try "View selected" (after selecting an object in Outliner), does that recenter your view so you can see the objects?

It does work when you are using the Defocus Node, using the Z-Buffer of the current scene. Could be that this is the only node that does actually trigger a render update, but then the Auto Render button would be quite misleading indeed.

Ah, thanks for the clarification! :)

Turns out, I was wrong. The issus got a bit better, but there still is a significant slowdown happening.
I have prepared a file with the default world, no lamps, just the 2 objects (camera and mesh from your file). There are 2 keyframes, on frame 1 it renders fast, and frame 2 it renders slow.
I have tested with latest master as well as 2.79a. So I would say, bug confirmed.

Wow, what a weird file! I can confirm there are differences in render time, but could not figure out why. I tried with not light source, with a different camera, with a different world, with no materials.
Still the same problem, in some rotation it renders really fast, and then, the more I increase the rotation, the render time increases as well.
It also doesnt depend on the camera angle, since rotating the object and the camera together still produce the same issue. However, copying the object and the camera and pasting it in a different file seems to eliminate the problem. Weird!

@Dalai Felinto (dfelinto) I am wondering if it even makes sense to have an EEVEE setup at this point. As far as I can see EEVEE does not have something like a shadow catcher, nor can collections ins view_layers be set to holdout, which is both kind of important for a working setup. So I would first make it use Cycles.

I have managed to make the Setup_Tracking_Scene operator work without errors by disabling the old BI and layer stuff, now I am trying to make the renderlayer setup work again.
However, it seems as if there are some python bindings missing still.
To make the setup work I am planning to have 2 Viewlayers, Background and Foreground (as was already implemented in the new script), with two collections, "background" and "foreground". In the Foreground viewlayer, the background collection will be set to "holdout", in the Background view_layer the foreground collection will be set to indirect only.
I can make the setup work with the outliner View_Layer menu, however I could not find a way to do that via python. Something like bpy.context.scene.view_layers["Background"].collections["foreground"].holdout = True
That or at least something similar does not seem to exist yet.
Or if it does, maybe someone can give me a hint?

I will have a look. Maybe first just kick out all the old stuff so that at least the basic setup of constraints and background images work. Speaking of which, the whole camera background image stuff doesnt seem to work all that great yet. Footage is always drawn in front of objects, no matter the front/back setting in camera background images. Also the colors are completely off in solid mode.

As mentioned before it's a very useful feature, also works great after a bit of testing. So I guess from artist's side it can be committed! :)

The last revision that worked was this: https://developer.blender.org/rB59b4c675361b54b32b6238855fe4a82117cc48c7
Starting with this commit Blender hangs when using a filepath directly: https://developer.blender.org/rB08274433e1bd9db5a2a27e5d2f8862e9cc3f27f0
Maybe @Bastien Montagne (mont29) wants to have a look? :)

This one looks really useful, also works great. :)

It's an interesting feature. But I would want to be able to set the amount of frames that are blended and also to be able to turn it off. I think it could also be an extra operator with separate shortcut, or maybe a mod to G (like the operator modes of knife tools). Or it could be a mode to enable, like proportional editing.

Please attach a blendfile with the bug, otherwise we have no chance of looking into your issue. Also, please provide the information required in the bug report guidelines.

Let me guess: You are not in edit mode when you press "W"? However, that's hard to tell, since you did not attach a blend-file, as required by the bug reporting guidelines ;)

This is not a bug. The renderer has nothing to do with camera solving. The fact that you got different results has to do with slightly different positions of your markers in the 2 different attempts. In fact the position of the tracking markers is your biggest problem.
In the video you had put the markers only on a flat plane, and only in the very center of the frame. That's a problem. Instead you should try to cover as much of the frame as possible, and also different heights, not just a plane. In your example don't just track the markers in the center of your frame, but instead also track for example the scissors, the pencil, the background objects.