My use case is: Show an implicit default value in the presentation, that is derived dynamically. So when the value is empty, the property editor should show the default value according to some heuristic. A custom binding implementation could look like this:

My use case is: Show an implicit default value in the presentation, that is derived dynamically. So when the value is empty, the property editor should show the default value according to some heuristic.

For default values, you should use @DefaultValue or DefaultValueService instead of trying to solve this in the binding.

It all depends on the usecase as that would drive how the class is setup to be extended. For instance, StandardXmlListBindingImpl there is a protected initBindingMetadata() method so that subclasses can replace the standard behavior of reading annotations... etc.

The checkbox presentation actually has three state: default (either false or true depending on model), explicit false and explicit true. You can tell the difference between the default state and explicit state via the light bulb near the checkbox, which is only present if the state is explicit.

What you are talking about essentially removes explicit false state. I wouldn't advise doing this, but I do not see any harm in accommodating this. If extending StandardXmlValueBindingImpl would be helpful in this case, either re-open the existing enhancement request or open a new one.