EL "#{msgs[greeting]}" (without quotes) is a correct EL, because [greeting] may be resolved in runtime to a property name, but there is no way to know it in design time, so that it does not matter at all if [greeting] is resolvable or not. There is enough information in EL model to tell this case from "#{msgs['greeting']}". In the first case the argument is an instance of ELPropertyInvocation, in the second case it is an instance of ELValueExpressionImpl. But you do not need even that. Just look at the implementation of BundleMap.getCall(). It works with the text value of the argument and strips it of quotes. All you have to do is to return null if there are no quotes to strip.

As to the error marker ["greeting" cannot be resolved], it is a bad idea to try to use it in the narrow context of this case. Visual editor may try to solve a general problem of displaying validation error/warning markers, then it should register IResourceChangeListener, filter events related to change of markers on the current file, and by there location find the visual location for them. This will certainly be a new feature, if we need it.