I'm not sure this is a good solution all things considered.
The main down-side from a user-perspective is the temporary un-synchronized state isn't maintained on any further selection operations, meaning it's a selection operation on an unrelated item will de-select the active object.

To give some concrete examples, using the default blend file with all outliner items expanded:

• Border select.
  • Select "Material"
  • Box Select "Light" object data.
    
    Notice the cube becomes de-selected (previously it would remain selected).

• Invert twice.
  • Select "Material"
  • Press Ctrl-I twice.
    
    Notice none of the objects are selected (previously the cube would be selected).

While these aren't exactly important use cases, when experimenting with this patch I often ended up with the active object becoming unselected when I was changing the selection of unrelated items,
including the edit-mode object being unselected when leaving edit-mode.

It's possible I'm noticing these issues more than users would because I'm looking out for inconsistencies, although I think the edit-object not being selected when leaving edit-mode is something users would notice.

Even so, it would be good if this can be solved without introducing unexpected glitches.

Note that from dev point of view I think it's worth keeping the mental modal for synchronizing as follows:

• Selection in the outliner flushes to the 3D view.
• Selection in the 3D view flushes to the outliner.

If we allow this to be out of sync, it violates this rule and IMHO it's hard to reason about what the correct behavior should be.

Alternative solutions could be:

• Allowing active-unselected, and remove this parent selection logic. (@Zachman noted this wouldn't work well for selecting bones with the driver display, although that could be resolved by always showing edit/pose mode armature drivers). Even though active-unselected is something we normally avoid, this patch is already setting active-unselected fairly often, so at least it would be done in a reliable way.
• Ignore object selection for outliner operations when it's data is selected (since the patch mentions this as a reason to add this functionality). This could be quite confusing, mentioning for completeness.
• Move further in the direction of this patch, solving the problem where a second sync call de-selects the object. This would require flagging to know which items changed and should be flushed, I'm not sure the complexity is worth it, noting it for completeness.

I don't have the mental energy to go over this problem now, but some 2 cents.

To go back to the previous behaviour of not selecting (in outliner) the parent, I think it is reasonable. As you said, it was changed just as a side-effect of a bug fix.

Note that from dev point of view I think it's worth keeping the mental modal for synchronizing as follows:

Totally agree. But how does that work for "data"? Given that we want (separate project, right?) to sync properties editor and outliner, then we also want to have the object select.

Thanks for taking a look here. I'll add some more details

To go back to the previous behaviour of not selecting (in outliner) the parent, I think it is reasonable. As you said, it was changed just as a side-effect of a bug fix.

The outliner data parent select behavior has existed for a while now, but adding synced selection in 2.81 it was removed (unintentional - regression on this edge case). The code still activated and selected the parent object, but because the element was not selected in the outliner it was deselected in the sync step. The issue that first brought this to my attention was T74332: driver can't be seen in the driver editor(blender2.82). In that case selecting a child bone would not select the armature making it impossible to edit drivers on the bone. The fix was to just ensure the parent elements were selected (as they should have been in 2.81).

A few issues have arisen from this fix though.

• The context menu (which is getting fixed in gsoc) currently takes the object/collection selection status into account. So a right click on a material or modifier for example no longer shows the modifier context menu entries. This makes it difficult to delete modifiers from the outliner, requiring the parent object to not be selected.
• Some context menu operators don't expect the object to be selected. For example T79187: "ID Data" → "Make Single User" in Outliner for Curve animation data crashes Blender had a crash because the parent element was selected when it wasn't before 2.83.
• And (in my opinion) the parent highlight is distracting/annoying :) although it is technically correct.

So the context menu could be fixed, but I still find it odd to see the parent highlighted when I select a modifier datablock, for example.

I wrote this patch as a simple fix (knowing fully that is was not the most ideal solution), but hoping it could be brought back to 2.90 and 2.83 to resolve some of the selection annoyances that currently exist there. Looking forward, I think a better solution could be made.

It's possible I'm noticing these issues more than users would because I'm looking out for inconsistencies, although I think the edit-object not being selected when leaving edit-mode is something users would notice.

This is true, I think in the majority of cases users are happy that a select all in the 3D view will sync to the outliner, and a box select in the outliner will sync to the 3D view. However, I agree that edge cases should be avoided.

I think the best solution is to activate the parent, but not select it.

• Selecting the data and having the parent object selected isn't my favorite behavior because elements outside what you click on suddenly become selected.
• Some cases already support the active-unselected logic. The shader editor properly shows the node tree for materials selected in the outliner when the parent is active-unselected
• Some cases don't support it. Drivers in the graph editor are one case (it appears the graph editor in general)

The "separate project" that @Dalai Felinto (dfelinto) mentioned is T63991: Outliner/Properties syncing which is not changed by this. So long as the parent objects are active, setting the properties tab works.