My most basic issue with this proposal is that it empowers scoped
enumerations *specifically*.

Scoped enumerations are not a higher-order enumeration type, with
unscoped enumerators as some kind of legacy features. Unscoped
enumerations are *enumerations*, with all of the powers of a scoped
enumeration with exactly three exceptions:

1. Enumerators of unscoped enumerations can be accessed in the scope
of the containing namespace/class. Note that they can *still* be
accessed in their own scope
2. An unscoped enumeration value can be implicitly converted to an integer type.
3. Unscoped enumerations have a default underlying type which is not
fixed. Note that they can *still* be given an underlying type. And
even if it isn't fixed, they do still have an underlying type which is
defined at compile time and accessible via
`std::underlying_type_t<E>`.

None of these differences have anything to do with any of the features
you're talking about. If it is useful to enumerate the values of an
enumeration, it is *equally* useful to do it to an unscoped
enumeration as it is a scoped one.

I cannot imagine when it would ever be useful to constrain a template
based on whether an enumeration was scoped or not. The proposal that
added `is_scoped_enum` had only one use case: unit testing to make
sure that types were properly converted to scoped enumerations. I see
no need for conceptualizing something on this basis; a `static_assert`
would be just fine.

Besides this, I find some of the functionality poorly defined as to
what you mean. What is the "position" of an enumerator, for example?

Personally, I think we only need a few features. Given an enumeration type:

1. Return a fixed-size array containing all values of enumerators in
that enumeration. This should be `constexpr`.

2. Return a fixed size array whose values are pairs of strings and the
underlying type of the enumerator. The strings are pointers to
NUL-terminated string literals containing the name of the enum, and
the value is the enumerator value for that enum. This function should
be `consteval`. The order of the pairs in the array is required to
follow the declaration order for the enumeration.

>From these two functions, you can build any runtime mechanisms you
want. If you want a function to convert strings into values of the
enumerator, you can write that by storing the array internally. You
can give it whatever error mechanism you prefer. If you want some kind
of one-size-fits-all runtime solution, we could add a type that
queries the array and bundles them together as appropriate.

Note that this should work for *any* kind of enumeration. And note
that this would not interfere with reflection. These would simply be
convenience functions, which could be implemented *through*
reflection. And we'd want those convenience functions even if we had
reflection.