I think the idea of allowing some conversions to be non-narrowing is fine in principle; there are some parts that really need elaboration though.

I'm not really sure what the motivation here is for instance. The examples with your wrapper class templates are contrived because in generic code, you don't use list-initialization due other issues with narrowing conversions and due to std::initializer_list constructors. You list forwarding as a motivation, but perfect forwarding should never use list-initialization in the first place.

I also don't find the argument that a library solution cannot work convincing. List-initialization cannot cover loss of information between possible future standard library types like std::big_int, between existing types like std::complex, etc. There is no customization point to define certain constructors as narrowing or "list-init-deleted", so preventing information loss via list-initialization is incredibly half-baked. It may have been a mistake in hindsight.

What I would like to see in the paper above all else is a concrete real-world motivating example.

+1. The current paper's "int to double" is the skeleton of a good example, but it's not a real-world example because

int32_t i = runtime();
double d{i};

is not itself code that a real programmer would write. We need more "novelistic detail" in that example. Ideally, take an example from a real codebase. Taking an example from a real codebase will necessarily mean also showing how people work around this today, since the code you want to write won't compile today. This will naturally lead to a Tony Table: "today's workaround" on the left, "what I want to write" on the right. And that will force you to explain why you want to write curly braces here: why is the workaround (presumably `double d = i;` which is a perfectly natural idiom as far back as K&R C) not attractive to you?

Important formatting nit: Please move "Proposed wording" to the bottom — below "Why a library-only solution is inefficient" — and actually show the diff, using <ins> and <del> markup (green and red), and showing all of sentence 7 for context. Saying "Replace bullet 7.3 with..." is technically unambiguous, but it's not reader-friendly. At the very very least, please give a hyperlink to the current [dcl.init.list]!

Wording: The current wording uses the cumbersome phrase "will fit into the target type and will produce the original value when converted back to the original type." You add a bullet point using the shorter phrase "can exactly represent." Are these two phrases supposed to be synonymous? If they are synonymous, please pick one or the other and use it consistently. If they are not synonymous, please explain the difference — and explain what will break if we fail to capture that difference in the wording.

Wording: I wonder whether at this point you could just eliminate (7.3) and add "or floating-point" to (7.4):

my $.02,

–Arthur