T53500 gives an overview of what still needs to be done for library overrides as a whole, it suggests ways to address some of the points listed here.
Intend of this task is to take a step back and give a list of concrete usability paper-cuts that would be good to address. It is mostly based on a feedback video by @Andy Goralczyk (eyecandy). The possible solutions can be discussed here too.

• There is no straightforward way to duplicate an override. (74ec37b70cbc)

• The UI feedback on override status is unreliable (fd8d245e6a80)
  
  To work around performance issues, only a single data-block is evaluated for UI feedback after calling the "Make Library Overrides" operator. Unfortunately this makes library overrides appear broken/buggy.

• Collections must be linked as instances for "Make Library Overrides" to work on the entire collection contents. (rB680a81fc4907)
  
  While not a big issue in practice, this could simply be addressed by letting the "Make Library Overrides" operator act on contents of a collection only, if the collection is not instanced.

• After the "Make Library Overrides" operator is run on a collection instance, the entire hierarchy of the overriden collection is expanded by default. (417ebc3845fd)
  
  Collections are expanded by default, we should probably make an exception for linked ones, which tend to have many items. D7626

• After the "Make Library Overrides" operator is run on a collection instance, the overriden collection gets placed in the scene collection; the instancer empty is still there, but typically unused. (rBbd3ab27410ef, rB174332688936).
  
  The overriden collection could be placed in the parent of the instancer empty, and the empy unlinked (or remove if this was the only user). D7626

• Materials are not linked with collections (so object materials can not be overriden) This is not part of this task, it's a later step in the roadmap.

• When overriding an object within some linked (not instanced) collection, all its linked parent collections have to manually be overridden. (rBe3fd60b182f6, rB680a81fc4907)
  
  There could either be an operator(-option) to automatically override parent collections, or the code would always do this.

• Library overrides can not be fully reset (i.e. removing all override operations, and reloading data from linked reference).
  
  Note that by default, this should not clear overrides of ID pointers, not even sure we want to give that option to the user? Would nuke all overrides in dependency hierarchy as well...

• Library overrides can not be removed entirely (i.e. deleting the local override, and relinking its usages to the linked reference). rB4aa04b64904b: LibOverride: Add 'delete and use linked data' operation.
  
  Note that this will likely also require purging other overrides that were only used by the removed override.

• Library overrides can not be regenerated from source linked data (to take into account e.g. changes in relationships between data-blocks...). rBaeaf2b0dd437: LibOverride: Add initial version of 'resync' operation.

This requires doing a proper complete re-creation of the override, then copying existing valid overrides properties to new ones, remapping 'external' pointers to old overrides to new ones, and finally deleting old override data-blocks.

• Library overrides can not be disabled This is not possible by design, overrides do not store any value, so it would not be possible to keep edited values from overrides and restore them when un-muted.
  
  The overrides should be listed in the outliner, with an eye icon to enable/disable them. D7631

• Even if no value is actually overriden, a library is still marked as overriden. This is expected and required behavior, being an override is a major status info of a data-block, whether some of its data are actually changed or not is irrelevant.

(There are a few other issues mentioned in the video, but these may be bugs that are already addressed. Needs to be checked still.)