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".