Proposed resolution (March, 2016):

Change 12.2.4.2 [over.best.ics] paragraph 4 as follows:

...and the constructor or user-defined conversion function is a candidate by

• 12.2.2.4 [over.match.ctor], when the argument is the temporary in the second step of a class copy-initialization, or

• 12.2.2.5 [over.match.copy], 12.2.2.6 [over.match.conv], or 12.2.2.7 [over.match.ref] (in all cases), or

• the second phase of 12.2.2.8 [over.match.list] when the initializer list has exactly one element that is itself an initializer list, and the target is the first parameter of a constructor of class X, and the conversion is to X or reference to (possibly cv-qualified) X,

user-defined conversion sequences are not considered. [Note:...

[Adopted at the June, 2016 meeting.]

The resolution of issue 1467 made some plausible constructs ill-formed. For example,

   struct A { A(int); };
   struct B { B(A); };
   B b{{0}};

This is now ambiguous, because the text disallowing user-defined conversions for B's copy and move constructors was removed from 12.2.4.2 [over.best.ics] paragraph 4. Another example:

  struct Params { int a; int b; };
  class Foo {
  public:
    Foo(Params);
  };
  Foo foo{{1, 2}};

This is now ambiguous between Foo(Params) and Foo(Foo&&).

For non-class types, we allow initialization from a single-item list to perform a copy only if the element within the list is not itself a list (12.2.4.2.6 [over.ics.list] bullet 9.1). The analogous rule for this case would be to add back the bullet in 12.2.4.2 [over.best.ics] paragraph 4, but only in the case where the initializer is itself an initializer list:

the second phase of 12.2.2.8 [over.match.list] when the initializer list has exactly one element that is itself an initializer list, where the target is the first parameter of a constructor of class X, and the conversion is to X or reference to (possibly cv-qualified) X,