> Would it make sense to define a general
> `completion-metadata-override-get` function instead of
> `completion--display-sort-function`?

Thanks for the suggestion, Daniel.  This is used now in a new patch below.

> This function could be used to look up the other meta data
> functions too, `display-sort-function`, `annotation-function`,
> `affixation-function`, `group-function`, etc.

All these meta data functions could be added later to
completion-category-overrides after pushing the current patch.

> (defun completion-metadata-override-get (metadata prop)
>   (if-let ((cat (completion-metadata-get metadata 'category))
>            (over (completion--category-override cat prop)))
>       (cdr over)
>     (completion-metadata-get metadata prop)))
>
> I suggest to use `if-let` instead of `let*`, such that an override is
> not retrieved if the category is nil.

Maybe customization of completion-category-overrides could support
a catch-all category `nil` for completions without metadata, like
e.g. `nil` can be used in .dir-locals.el as a catch-all for all modes.
But I'm not sure how useful this would be.

> Besides that, in the `completion-category-overrides`, you use
> `completion--sorting-type` for the `display-sort-function`, while it
> should just be `function`.

A new patch doesn't use anymore `completion--sorting-type`
since there is a small difference between customization choices
in `completions-sort` and `completion-category-overrides`:
`completion-category-overrides` needs the value `identity`
that prevents a fallback to `completions-sort` as `nil` does.