_mcd_client_registry_list_possible_handlers() currently only uses the given PreferredHandler (if non-NULL) as a last resort, if there are no matching handlers.

In the "normal" dispatching code-path, other code in mcd-dispatcher.c and mcd-dispatch-operation.c special-cases the PreferredHandler (separately) and tries it before the PossibleHandlers, so this is OK.

(As of commit 34e8ab1f4b4e: for delegation, add_possible_handlers() specifically prepends the preferred handler to the list of possible handlers to which it will delegate; for an Ensure operation on channels waiting to be dispatched, _mcd_dispatcher_add_channel_request() calls _mcd_dispatch_operation_approve() with the preferred handler, if any; and for channels created in response to a request, mcd_dispatch_operation_set_property() extracts the preferred handler from the request and calls _mcd_dispatch_operation_approve.)

However, special-cased parts of the dispatching code path, such as Bug #40283, have started to use _mcd_client_registry_list_possible_handlers() (directly or via mcd_dispatcher_dup_possible_handlers()), in a way that passes in a preferred handler but does not then special-case it like this.

I think it'd be less confusing if _mcd_client_registry_list_possible_handlers always included the given preferred_handler (if non-NULL) at the head of the list. We could then refactor add_possible_handlers() to assume this. The special cases involving _mcd_dispatch_operation_approve would have to stay anyway, due to their secondary function of "mark the CDO as approved".