[over.best.ics.general] p1 says

An implicit conversion sequence is a sequence of conversions used to convert an argument in a function call to the type of the corresponding parameter of the function being called. The sequence of conversions is an implicit conversion as defined in [conv], which means it is governed by the rules for initialization of an object or reference by a single expression ([dcl.init], [dcl.init.ref]).

[over#best.ics.general-9] says

If no sequence of conversions can be found to convert an argument to a parameter type, an implicit conversion sequence cannot be formed.

[conv#general-3] says

An expression E can be implicitly converted to a type T if and only if the declaration T t=E; is well-formed, for some invented temporary variable t ([dcl.init]).

Consider this example

struct A{
  A(int) = delete;
};
struct B{
   B(int) {}
};
void fun(A);  //#1
void fun(B);  // #2
int main(){
    fun(0);  // #3
}

The intent of the rule is to make the call be ambiguous. However, according to [conv#general-3] says, since A t = 0; is ill-formed, hence we could say 0 cannot be implicitly converted to a type A, hence the implicit conversion sequence cannot be formed? #1 is not a viable function? Furthermore, for a parameter "lvalue reference to int", the argument is a bit-field of type int, according to [conv#general-3], it is also ill-formed except that [over.ics.ref#4] explicitly permits that

Other restrictions on binding a reference to a particular argument that are not based on the types of the reference and the argument do not affect the formation of an implicit conversion sequence, however.

I think these rules are contradictory.