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 the perfect scene management solution, solving all previous limitations and shortcomings.

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.

Not sure how this is planned to be handled in the new keymaps, but one other possibility for keymap settings is the behavior for move/rotate/scale hotkeys.
Will old behavior for direct operator invoking (grab/rotate/scale) be kept in parallel with the new tools workflow?

In T57918#557595, @Brecht Van Lommel (brecht) wrote:

When starting over an unselected node, it would do transform tweak of that single node.

Sounds about right.

Not sure if this is technically feasible, or even desirable, since we don't have multi-state buttons anywhere else in Blender.
We could save a lot of space in the collections popover if we combined the visibility and selectability buttons into a single multi-state toggle.

In D3743#89988, @LazyDodo (LazyDodo) wrote:

We got a native crackle a while ago, grab a nightly build at http://builder.blender.org and enjoy.

This seems incredibly useful! Would a "Voronoi Cracks" version also be possible?

In D3400#89842, @Germano Cavalcante (mano-wii) wrote:

You can check what is happening by enabling the Bounds view in the Viewport Display panel of the object,

If possible I'd rather keep per object type selectability in the popover, instead of per object type visibility, if only one can be kept.
Reasoning is that we already have lots of ways to control visibility, but selectability can only be set from the outliner.

I see in that case a few controversial ones that come to mind.

How would these options differ from editing the keys directly in the keymap?
Are they just quick toggles or easier ways to swap stuff around, without requiring digging into the keymap, or avoiding conflicts?

After these improvements snapping to bezier curve objects doesn't seem to be working as expected in 2.8.
There seems to be some sort of offset when spanning curves to other geometry. Snapping meshed to curves appears to work as expected though.

Holehartedly agree with all these, especially

In T57880#554790, @William Reynish (billreynish) wrote:

• When hitting Ctrl/Cmd-S. to Save, do it immediately, and show the Status Bar message
• When using Del key, delete immediately, and show the Status Bar message
• Keep X key working as it does now

My greatest gripe currently is with the position. It is actually tucked to the left, but because the toolbar has variable width, and doesn't always reach the bottom it often looks random and misplaced.

In T57718#551757, @Brecht Van Lommel (brecht) wrote:

Shouldn't it be the other way around, rename the other primitives properties to be "Size"? The Cube or Monkey having a radius is a bit odd.

The floating redo panel could also use some redesign, it currently looks out of place because of the toolbar.
Perhaps centered at the bottom of the viewport, ideally movable/draggable anywhere in the 3D View

Maybe some sort of highlight hover effects encompassing all draggable properties/buttons.

That looks pretty good already, very useful, many thanks.
Only suggestion I can think of is perhaps to draw some sort of local Z axis pointing to the current tilt direction, to make it clearer to the user where it is currently facing.
If possible even two axis one for X and Y. Bonus points if these axis are actually capable of snapping to other geometry, for precise tilting.

This is shaping up to be an excellent upgrade to general usability.
My only concern so far is that I think Select All operator should be mapped to Ctrl + A, in the name of keeping up with "industry standards".
It is the common select all in many applications, and the default behavior in operating systems, like the file manager, lists of items, or text input boxes, among others.