I think the paper is dead on arrival.
If you have a solution that relies on explicitly enumerating the encodings then you are just asking for trouble, because:
a) You will be stuck maintaining an ever growing list of encodings, and have people fighting who's encoding is relevant to make it onto the list
b) it is a dead end if the encoding you want to work with is not on the list.

A proper solution should allow a user to extend support by themselves and not have to wait for a committee.
It's a hard pass.
________________________________
From: SG16 <sg16-bounces_at_[hidden]> on behalf of Jonathan Wakely via SG16 <sg16_at_[hidden]>
Sent: Tuesday, 27 October 2026 18:24:36
To: sg16 <sg16_at_[hidden]>
Cc: Jonathan Wakely <cxx_at_[hidden]>
Subject: [isocpp-sg16] P4246R0 Transcoding Text Views and Ranges for WhatWG and iconv

I know the paper mentions Eddie's P2728 (Unicode in the library pt 1) and compares them, but I'm not convinced that a completely different API with entirely different names is needed. That seems likely to confuse users.

There seems to be a huge amount of overlap between the codec enum and std::text_encoding::id, why do we need a new enum? Won't that confuse users too?

Why do we need a novel mechanism for mapping encoding labels/names to IDs, isn't that exactly what std::text_encoding does?

Is 'codec' a suitable name? (I don't see that term anywhere in the WhatWG Encoding spec). The paper proposes 'codec' as an enum for identifying an encoding, but then decode_codec and encode_codec as concepts that are modelled by classers that encode and decode ... so is a codec an enum identifying an encoding or a class performing it? It seems to be both. The WhatWG spec uses "encoder" and "decoder", but not "codec".