When one of the binding is not resolved the converter will receive a DependencyProperty.UnsetValue in the corresponding index of the 'values' array.
Is that what you are seeing?

You're right, it's DependencyProperty.UnsetValue. Thank you!
So I have to use FallbackValue or compare each value with the UnsetValue.
I was totally unaware of this feature as I've rarely used IMultiValueConverter (it was added fairly recently).

I was assuming it's some kind of data corruption. The issue happened with a quite complex data binding case like this one:

<hud:HUDButtonBadgeControl.Number>

<MultiBinding Converter="{StaticResource ValuesAdditionMultiConverter}">

<Binding Path="SomeInstance.DataContext.CountA" />

<Binding Path="SomeInstance.DataContext.CountB/>

</MultiBinding>

</hud:HUDButtonBadgeControl.Number>

Regards!

By the way, is it expected that FallbackValue provides "False"/"True" as a string instead of bool and "1"/"2"/"3.0"/etc as a string instead of the integer or floating-point number? It's quite complicated to use.

Suggestion: define a new private class in C# SDK: DependencyPropertyUnsetValue. Use it specifically to return a singleton instance for DependencyProperty.UnsetValue. So library users like me will see it in the debugger and/or exception message, and understand that it's not a bug with some corrupted data being passed in.
I was just thinking on exactly that because C# users shouldn't see any reference to BaseComponent. This will also apply to Binding.DoNothing value.

By the way, is it expected that FallbackValue provides "False"/"True" as a string instead of bool and "1"/"2"/"3.0"/etc as a string instead of the integer or floating-point number? It's quite complicated to use.
Yes, in WPF you will also receive the FallbackValue as a string, the same for the CommandParameter.

Now DependencyProperty.UnsetValue and Binding.DoNothing show with the right name when debugging in C#.