P1885 presents an "extension point" of sorts with its aliases() interface.
In addition to the aliases listed in the IANA character set registry,
implementations may introduce additional strings.

This raises a question:
What strings should implementations consider as candidates for adding?

On the surface, one possible source for additional aliases would be ICU.
Looking into ICU, however, will lead one to notice that:
It uses the same converter for csShiftJIS and csWindows31J.
It has a concept of ambiguous aliases.

At least in some cases, these ambiguous aliases in ICU arise because ICU
collects aliases from various sources (different implementations or
environments; ICU calls these "standards" and an alias for a converter may
be "tagged" as being from zero or more standards) and these sources may
associate an alias with subtly different character sets.
More generally, aliases in ICU are not aliases for all purposes (i.e.,
aliases in the identity or strict validation sense), but instead aliases
meeting the design requirements of ICU.

Since P1885 intends to "reliably identify encoding across implementations
and systems", it would seem that, in practice, aliases must come only from
widely-accepted sources that agree with each other.
More practically, under the current design, the bar for adding an alias to
the implementation-defined list should be very high. I do not think that
the paper makes this obvious.

A design that incorporates tags in the style of ICU might be more flexible
(and it may be possible to add this later if the current aliases are
understood to be a curated subset).

As it is, I think it is worthwhile to revisit whether the generality of the
implementation-defined behaviour is advisable. It seems that, as the paper
evolved, at least one implementation-injected alias was meant to be the
"preferred name" on the system returned or recognized by various APIs
(e.g., iconv_open). Even that is problematic: There is a tendency in
converter applications to treat a de facto "reigning" extension as being
what is meant when the non-extended standard is requested. In highly
architected environments, the csShiftJIS and csWindows31J "problem" that is
present in ICU would manifest as there being only one API-recognized
"preferred name". The present design intent of P1885 in having
non-overlapping sets of aliases is in conflict with the desire to associate
the "preferred name" as an alias in such situations.