Description
Protocol buffer definitions are designed to change over time and remain compatible with old software and data. In particular, it is safe to define new messages, enums, services, etc.
However, CEL interpretation of qualified identifiers depends on the non-existence of entities in the namespace. When interpreting a sequence of period-separated identifiers, CEL prefers longer names over field selection. For instance, given a.b.c, CEL attempts to interpret as name a.b.c, then field c of a.b, and finally field c of field b of a. The latter interpretations depend on the prior interpretations not appearing in the namespace.
Lastly, to avoid surprises for users, CEL has user-defined functions "shadow" any built-in functions in the function namespace, and user-supplied variables "shadow" other bindings in the identifier namespace. This is necessary for updates to the built-in functions and identifiers without breaking existing CEL expressions.
So an expression a.b.c as a selection of fields .b.c or just .c might change its interpretation if presented with an updated protocol buffer environment containing a newly-defined entity a.b.c or a.b.
There is a convention in Prototcol Buffers to give entities uppercase names, and a convention in CEL to name variables in lowercase, preventing such a problem. But CEL users don't necessarily have full control of the protos they need to import, and we'd like to have a stronger claim than "CEL is stably by convention".
To prevent this, CEL would have to first attempt to interpret a.b.c as a use of user-supplied variables a.b.c, a.b, or a in that order, before looking for entities supplied by the proto environment.