Hmm, this is an interesting idea.
@dynamicMemberLookup provides a great syntactic sugar, but I feel its usefulness is limited because for most use cases, accepting arbitrary string indices (literally any nonempty string) is too general.
More safety is often desirable. I felt this strongly when writing tests for the @dynamicMemberLookup PythonObject struct. Any typo you might make (e.g. numpy.fill instead of numpy.full) will pass type-checking. Such typos were difficult to debug and left me scratching my head for a while. Thus, with the current design, it seems that informative error messages in subscript(dynamicMember:) (and dynamicallyCall) methods are essential for usability. This is kind of a smell to me: the usability of a language feature shouldn't rely so heavily on diagnostics.
Without more safety, declaring @dynamicMemberLookup on SIMD vector types seems undesirable to me. There's much room for typos/errors and too little safety.
This pitch certainly addresses a real problem. I need to think more about it, but the idea seems promising because enum-typed indices can still be sugared in a simple-ish way, as you show in code. Interested in others' thoughts!