When one is making an effort to rename things and keep a scene tidy it is a frequent action to rename both the object and the data at the same time so having both in the same dialog would definitely save quite some clicking around for two very related actions.

Not sure if this is entirely related or technically feasible, but since settings are being moved it sounds like a opportune moment to propose such changes.

These seem to improve clarity substancially.

In T61578#623163, @Andrzej Ambroz (jendrzych) wrote:

What's wrong with this?

Agree, a lot more readable. Additionally with your proposed layout we gain collection icons aligned with child objects which also looks tidier and easier to follow.

I do like this order a lot more, it seems more organized and logical.

In D4359#98906, @Pablo Vazquez (pablovazquez) wrote:

In D4359#98903, @Duarte Farrajota Ramos (duarteframos) wrote:

PS: Please always use 2.8 for screenshots as it can get confusing for users and developers.

I would happily aprove of this change. It would single handedly solve the problem by making it immediately discoverable, at the (IMHO small) expense of a little a little getting used to the new behavior.

Not sure if it can be addressed by this patch, but it seems related.
In the RGB curves node, the wrench icon menu opens sideways to the right of the button, unlike any other, which can get annoying.

In T61492#619509, @William Reynish (billreynish) wrote:

I think the numbers for collections is a weak concept to begin with. When you have nesting and unlimited numbers of them, the 1-9 numbers don’t map logically very well.

I would oppose removing the ability to set renderabilty and viewport visibility independently.
It is one of the current strengths of Blender and one of the things I really like about it.
There are several cases where you want objects visible in the viewport but not renderable. Here are a few:

This would indeed be a welcome addition to bring back. Would it also be possible for the pop up to allow renaming of object data as well?

I agree with William I believe it is just a miscommunication issue, more specifically a matter of using the correct icon and label.
As I have mentioned before, if we named it something along the lines of "Freezing" and changed the icon to a snowflake or similar (if copyright doesn't get in the way) it would solve most confusions

Just though it could also integrate to the camera view gizmos, but your solution is indeed a lot more consistent.
It also turns the viewport text into something functional, instead of static text.

A popover menu to pick currently active camera would also be very welcome.
Something akin to what we can currently do from the Scene tab of the Properties Editor.
It is currently hard to quickly browse through all cameras views in a scene.

In D4298#97343, @Harley Acheson (harley) wrote:

But if those colors are important, and specific colors are expected, then I *could* make them dynamically too.
Or I could take the specified theme color and try to make it darker or lighter. However that has some pitfalls. It would work correctly if the theme designer used a color with some latitude, like a mid-green so I could shift it into a light or dark green.

For location and rotation randomization, an option to toggle between transforming along local (object) axis or global (scene) coordinates would also be very welcome.
For scale we only need to keep the Scale Uniform option

In rB2cc69a5e2023ddc5a6a6ebed16a5d9ea3af2eaef#215829, @Clément Foucault (fclem) wrote:

This does work for all surface types.

This used to be only supported for mesh objects in pre 2.8.
Would it be possible to add transparency support for other object types, namely bezier curves as well?

My mistake then, it does look good; especially the more blurred version test, even if the do merge a little with the borders or each other.

I tend to prefer cleaner looks, but it does improve readability in some situations.

Having no active item is a idiosyncrasy I have found before in previous versions of Blender, never been an actual problem, but is curious case to tackle.
Here is a more complete laydown of all the distinct cases I could think of, hope it helps you get this right.

This is really going the right way! With all items in this proposal implemented, and Shift-Click to fill selection enabled, the outliner finally becomes almost perfect, solving all previous limitations and shortcomings.

Looking pretty good so far, huge improvement. Only one small nitpicking.
The save button is perfectly aligned with the preference categories tabs, and is exactly the same size and style. It looks way too much like one of them despite being a completely different type of UI element.
This might be potentially dangerous for the user accidentally saving changes instead of switching tabs.

Would these changes make it easier to fix T51886 limitations?

"Positions Only" reflects much better what the option does, since scaling or rotating don't affect object scale or rotation, nor its geometry; only its coordinates in the scene.

All these look great, I particularly like the first and third set
The straight up and down arrows may look like download/upload or save icons though, so I think the third set with "Bent Arrows" would be the way to go.

In T58167#565630, @Andrzej Ambroz (jendrzych) wrote:

I still prefer simplicity of current design, though.

I really don't see what the issue is here, current icons are perfectly fine.
Either way it is quite irrelevant, direction is completely arbitrary.
I don't think there is any convention for this, both would be explicit as long as it follows some logic.

I have also run into this issue. As Brecht mentions the only current workaround I have found was opening a second outliner in Orphaned Data mode and dragging it into the view layer outliner

In T57857#559366, @Brecht Van Lommel (brecht) wrote:

Merging hide and viewport visibility icons as suggested by @Julien Kaspar (JulienKaspar) seems promising.

Yes, I meant the glyph, I apologize, I lacked the proper lingo. Edited comment above for clarity.

I strongly believe the eye icon should remain in the outliner for all objects, ideally along viewport visibility functionality.

In T57902#559092, @Campbell Barton (campbellbarton) wrote:

Currently there are no plans to remove direct operator access. The industry-compatible keymap will likely work this way.