I think the presented design is almost okay, even with the complexity of legacy encodings, but one thing raised my eyebrows: > If your type always has a replac

I think the presented design is almost okay, even with the complexity of legacy encodings, but one thing raised my eyebrows: > If your type always has a replacement character, regardless of the situation, it can signal this by writing one of two functions: replacement_code_units() (for any failed encode step), replacement_code_points() (for any failed decode step). They (and their cousins maybe_replacement_code_units/points) do not accept any argument, and that's wrong. There are stateful encodings like ISO/IEC 2022 and HZ where you might need the current encoder state to select a correct replacement character. For example `?` might not be representable in the current state and needs a switch sequence. You can, fortunately, always switch to the desired character set in 2022 with a fixed sequence so you can do have a fixed replacement sequence there, but you can't do so in HZ. It is technically possible to force-switch to the default state when an error is occurred, but not all users will want this behavior. It should obvious to anyone that stateful encodings are in general PITA.