Currently, users on a non-graphical, non 24-bit Emacs who provide their
own `erc-nicks-colors' pool must ensure those colors fall within
`erc-nicks-contrast-range' and `erc-nicks-saturation-range' (assuming a
non-nil `erc-nicks-color-adjustments', the default). Otherwise, their
pool is subject to culling without warning on module init, which they
may find frustrating even though this behavior is documented. If people
believe this to be a grave enough annoyance, we can do something like
the attached, which offers a couple alternate pool-prep approaches that
"pre-treat" candidates with `erc-nicks-color-adjustments' and coerce
them to predefined system palette members, thus effectively culling by
way of deduping.

If actually doing this, we'd likely have to add a public-facing knob
for selecting between various fixed-pool filtering styles, such as:

 - cull (current)
 - treat, coerce, and cull
 - treat and coerce

The latter two differ in that the first rechecks if the remapped
"defined" value still falls within specified tolerances, and drops it if
it doesn't, while the last approach turns a blind eye. IMO, the first is
of limited value unless we were to make it try repeatedly to find a
satisfactory match. Although these only run on init, folks may find them
too sluggish (both are already quadratic). We could instead make them
interactive commands (or `custom-set' functions) that users can use to
populate `erc-nicks-colors' while configuring.

Personally, I'm not affected by the current behavior because I use
graphical Emacs or a 24-bit terminal emulator with ERC. However, I'm
open to doing this if others think it worthwhile. Thanks.