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