I recognize the reported bug is there, and I will look into fixing it (99% sure I introduced this in d1ef6be4a770.
That said I think this patch is wrong.

Thanks for the patch, committed in the 2.80 repository.

For the records, it works fine with release builds. But since this assert is for "sanity reasons" it should be addressed eventually.

• From review: move logic inside WM_window_set_active_view_layer

"Viewport Rendering doesn't support Multi-View"

• It updates only the main window you edit and the non-main window children of this main one.

I would say same buffer too. It will be confusing to copy from outliner, paste into viewport and not see the objects you just copied.

Alright, committed the bit about selectability, but leaving this open to address collection (which may need to remove my code changes, anyways).
Also, there seems to be a strange bug where if I select the Cube, Ctrl+C, select all (Cube + Light + Camera), Ctrl+V it paste not only the cube but all the other objects as well.

Bug fixed already

The median value showed is for all objects iirc (not in my computer now). Bur editing only affects the active.

@William Reynish (billreynish) while the patch does nothing to the Redo panel in regard to showing the constraint axis, it allows you now to successfully change the orientation there.

Patch fixed. Technically this can be committed in two parts.

The patch as it is it is wrong.
But it also seems that a lot of the changes came from: rB1bfbfa281046b9d600a1604794fce3aadd7f5cf7 so perhaps the original bug was somehow intentional/by design? I will investigate a bit further.

For the records, users can reproduce this also by using bpy.ops.transform.mirror(). It basically fails to run via exec even when the constraint axis are set.

@Daniel Ulrich (dulrich) You can do it if you do it from the outliner. There you can select the elements and use M as well, but it will move all the selected in the outliner, not the selected/visible ones in the viewport.
I'm actually closing this since I don't think it is a bug. @Brecht Van Lommel (brecht) / @William Reynish (billreynish) let me know if you think otherwise.

You can reproduce this issue even with a single window.

Hidden objects are not selected, so they cannot be moved. Basically this is what is happening. What I may do is to take the active object visibility into account to poll the operator.

That's an interesting topic of discussion. This is not exclusive to creases, the same is valid for Transform for instance.
I would say the bug is that Alt+Edit a property in the UI is not working for edit mode, only object mode settings. Maybe in this case it should work without [alt] being required though. Not sure.

The bug was indeed happening in the version you mentioned. It seems fixed in master now though.

I believe pasting collections when pasting an object is a side-effect of unifying groups and collections. It is also quite handy and allow you to paste an entire scene keeping its hierarchy.
Now for the actual reported bug. Even in 2.79 the selection option is not working (although there the objects are always selected).

Hi @Julien Kaspar (JulienKaspar) I clearly expressed myself poorly. I agree with you and this is the exact behaviour that I implemented. But to be sure, please try a build after said commits, to see if this is what you had in mind.

Thanks @Brecht Van Lommel (brecht), committed as:

• rB4510f88d00a7
• rBb7d942446f8a

I can confirm this, it has nothing to do with T62320 though. I will try to debug a bit before assigning to someone.

This is intentional, by design.

Please specify the exactly hash of the 2.80 build you are testing. That said I don't think I can reproduce it. Is there any errors in your console window?

Basically in //release/scripts/presets/keyconfig/keymap_datablender_default.py object.hide_view_clear has select as False.
@William Reynish (billrey) do you know if this was intentional? If so I will make sure the outliner unhide objects operator also doesn't make the newly visible objects selected again.

Alright, the bug has nothing to do with the outliner whatsoever.
Basically the unhide operator in the viewport is not re-selecting the newly visible objects.

I cannot reproduce this here, it never hides when the outliner is in the Scenes mode.
And honestly I can't understand how can this possibly be the case since the poll to OUTLINER_OT_hide explicitly runs only for the view layer mode.

You mirrored the plane on itself. That makes the mesh to have double vertices allover it.
If you go to edit mode, and remove half your plane, and THEN use the Circle Tool, it works fine.

The patch (updated on - P934) seems to work (no crashes).
There are tons of dependency Cycles errors though (full list P935):

'OBArmature.Mario.POSE_IK_SOLVER()' depends on 'OBArmature.Mario.Spine.Bendy.BONE_READY()' through 'IK Chain Parent'               
'OBArmature.Mario.Spine.Bendy.BONE_READY()' depends on 'OBArmature.Mario.Spine.Bendy.BONE_CONSTRAINTS()' through 'Constraints -> Ready'
'OBArmature.Mario.Spine.Bendy.BONE_CONSTRAINTS()' depends on 'OBArmature.Mario.Spine.Tail.BONE_READY()' through 'Damped Track'          
'OBArmature.Mario.Spine.Tail.BONE_READY()' depends on 'OBArmature.Mario.Spine.Tail.BONE_CONSTRAINTS()' through 'Constraints -> Ready'
'OBArmature.Mario.Spine.Tail.BONE_CONSTRAINTS()' depends on 'OBArmature.Mario.Spine.Tail.BONE_POSE_PARENT()' through 'Pose -> Constraints Stack'
'OBArmature.Mario.Spine.Tail.BONE_POSE_PARENT()' depends on 'OBArmature.Mario.Spine.Base.BONE_DONE()' through 'Parent Bone -> Child Bone'
'OBArmature.Mario.Spine.Base.BONE_DONE()' depends on 'OBArmature.Mario.POSE_IK_SOLVER()' through 'IK Chain Result'

@Brecht Van Lommel (brecht) I have mixed feelings here. On one hand I can see why we would want to treat the Master Collection as any other collection when it comes to adding/removing from it.
On the other hand we don't allow the Master Collection to be instanced. So we are deliberately treating it as its own thing.

Please describe the steps to reproduce the bug. A video externally hosted is not considered valid for a bug report.

It doesn't make sense to tackle any of this until we address T61578. To add a keyframe from a callback button would be tricky.

@Arto Kitula (akitula) and @Sebastian Koenig (sebastian_k) I cannot reproduce it either on the mentioned hash, or the latest 2.8. Any change you get me a backtrace?
@Sergey Sharybin (sergey) can you reproduce in your end?

For the records, this is probably something more for @Campbell Barton (campbellbarton) than me, since a lot of this changed with the work to bring modes to workspace. Crash fixed though.

@Antonio Vazquez (antoniov):

//source/blender/editors/gpencil/annotate_paint.c: In function ‘gpencil_draw_status_indicators’:
//source/blender/editors/gpencil/annotate_paint.c:1674:2: warning: enumeration value ‘GP_STATUS_CAPTURE’ not handled in switch [-Wswitch]

I like this solution as well. At some point we may want to have a proper BKE_workspace_copy_data as mentioned by @Bastien Montagne (mont29) on D4489.

Alternate fix on rBb5349d967f1af433a9ee914aec72e028c3b2cd10 by @Brecht Van Lommel (brecht) .
My bad for not connecting the report with the patch. I forget that adding Fix T60855 in the summary header is not enough to link them.

It could check ob.base_flag (if it doesn't already, not looking at the code atm), although this is fragile since it takes the current depsgraph only. It is the same as 2.79 though.

Please check rBba4d07cc5c74e42445a59bf1e77587cbf4a83482 to see if it fixed the material issue.

This seems to be working. Since we never got the specific broken revision specified by the user, I'm closing now as invalid.

@Campbell Barton (campbellbarton) I have no idea what is so special about the workspace (tab) context menu, but it end up getting the "Jump to Target" option, which makes no sense there. Any idea what is going on here or if this fix is ok?