So the big thing one notices here, is that the ENUM function makes a lookup and conversion utility object, not something more like a DATATYPE!.
It's thus not surprising that the names are things like *FX-DX8 and *family as opposed to FX-DX8! and family!
If you can't use an enum as a type constraint on an argument to a function, it seems to me you're missing a large part of the value. So I'm definitely looking for something different...and I'd like to see something that can do enum parameterization
But it is worth asking if the thing you make with ENUM--even if it's a DATATYPE!--could have utility functions that could be called even if you don't have an instance of a type to work on. e.g. "static methods" on datatypes...
This strikes me as undesirable. In the past, Ren-C has used its ability to take the left-hand side of an assignment literally to capture the assigned-to thing's name.
enum: infix func ['left [set-xxx?] ...] [...]
Previously, picking up the left-hand set-xxx? could be optional... because there was <skip>-ability... and so if there was no SET-WORD! on the left you could just say it was anonymous. Skippability has been removed, however.
It's a dodgy mechanism, in any case. It would be nice if the system could retain this kind of information for you implicitly.
There's a facility by which ACTION!s retain the names under which they were last assigned. It costs a pointer in the Cell, and not all types have room for this. In fact FRAME!s do not, but they use the special case of antiform frames to say that the spot which would be used for a "Lens" is used for the name... if it looks in the Lens slot and detects that the pointed-to thing is a Symbol*, then it's a "Lensless" frame.
OBJECT! Cells do have room free--at this moment--for a cache of the last name under which it was assigned. So do DATATYPE! Cells--if they were what ENUM made.
We'd presume this would be tunneled through in the "this" pointer for methods, which is currently passed as . so you could say something like label of . to get it.
Since this is all getting glommed into one big OBJECT!, you couldn't name an enum value title* or assert or name, and any future extensions would compete with some enum values. I'm never crazy about these techniques which wind up imposing rules about what values you can't use in-band.
Ren-C can give different meanings to my-enum.foo and my-enum/foo (and also my-enum:foo ... I haven't really thought about what kind of axis of extensibility CHAIN! would have). But at least you could distinguish between enum states and functions offered by the enum itself.
(That raises a question of if this should be a feature of OBJECT! in general... could it have separate namespaces for non-methods and methods?)