I get that and I agree that the syntax is more concise. However I don't like that it doesn't integrate with the syntax parsing of expressions themselves (this can lead to unexpected interactions), and I also don't like that it is different from the way that expressions normally function with respect to the fact that property expressions generally resolve based on locally-available information. The syntax really makes one think that it's something happening at the property expression parsing level. I'd expect something like `${foo.bar?}` to have a behavior based only on aspects of the `foo.bar` expression itself; to have it default to some non-local value based on the *context* of the expression is really pretty unexpected in my opinion. Especially strange would be if I had an expression like "${foo.bar?}baz" and the default value for the property gets put in; at least if I have "${foo.bar:${default}}baz" or even "${default}baz", I can understand what's happening a little more clearly (i.e. that it's a concatenation and nothing more, not some kind of operator or something).
Having a reserved property name for the default value not only integrates cleanly with the expression parser, but it's also something that we could potentially carry over to Quarkus, SmallRye Config, or other tools which use expressions for configuration.