Dynalink currently encodes operations in the name of the call site, e.g. "dyn:getProp:color" or "dyn:new". Worse, this encoding is used in Dynalink as the official encoding of the operations. The approach is brittle, requiring a dedicated prefix ("dyn:") as well as string tokenization and string comparisons. 

It also forces a particular encoding at the call site. In reality, there's no need for Dynalink to prescribe that, as both the encoding (emitting bytecode) and the decoding (bootstrap method) are internal to a particular language runtime and never cross language runtime boundaries, therefore it should be left to a particular language runtime to choose the encoding.

A better idea is to introduce an Operation interface, that is empty (for similar approaches already in JDK, see e.g. java.nio.file.CopyOption). 
Also define an "enum StandardOperation implements Operation", providing the standard operations GET_PROPERTY, SET_PROPERTY, GET_ELEMENT, SET_ELEMENT, GET_METHOD, CALL_METHOD, CALL, and NEW.
To provide for named operation we need "class NamedOperation implements Operation" that is a tuple of (Operation base, String name), or even better (Operation base, Object name) - so that e.g. fixed Integer indices are supported too without having to encode them into a String.
Finally, to provide for alternatives (e.g. Dynalink's current "dyn:getProp|getElem|getMethod:foo"), we'll need "class CompositeOperation implements Operation" that wraps an Operation[]. 

With these, we can represent operations, standard operations, their naming and composition in a type safe manner instead of having to rely on a mini domain specific language whose expressions are passed around as strings.

An interesting consequence is that NameCodec no longer needs to be part of Dynalink, although we might keep it around as an implementation convenience for other languages.

A small drawback to the approach is that every language implementer will be forced to write their own operation decoder to be used in the bootstrap method, as Dynalink no longer defines the encoding. We might provide some convenience "simple operation parser" utility, although I'm not convinced about this.