Apologies for sending this so close to the start of the telecon.
The paper refers to RFC 3808 which established the "IANA Charset MIB" and specifically says:
However, [rfc3808] is from 2004 and has not been updated.
The paper should at least make some reference to the location of the location where the "IANA Charset MIB" is maintained: https://www.iana.org/assignments/ianacharset-mib/ianacharset-mib
. As of the document date indicated in P1885R5, the MIB module was last updated in January of the current year (2021). It seems this location was mentioned in passing on the SG16 reflector but with no emphasis on the significance.
Also, I find the choice of naming the accessor that produces the MIBenum value from the IANA Charset Registry "mib" to be unfortunate. It seems there are unambiguous precedent cases in libraries (including those for other programming languages) using "mib" to refer to MIBenum values, so this does not rise to the level of an objection. I see no reason for the paper to use the term this way in prose though. I do note that RFCs do seem to use the term not only to refer to MIBs but also to MIB modules (but a MIBenum value is neither a MIB nor a MIB module).
Regarding the naming of the enumerator values, I am not fond of excess "invention" here. There are names (beginning with "cs") in the reference documents. Using those names (including the "cs" prefix) makes even the "csUnicode" case "merely following established practice".
Regarding the underlying type of the enumeration: The corresponding definition in RFC 3808 uses ASN.1 INTEGER (which does not have a length limit).
Regarding the "environment" functions, I think the wording needs more work to address cases where the value of the LANG environment variable is changed.