There are libraries which generate the BindableProperty boilerplate based on a partial property or on a field annoated by some attribute. It can look something like this:

[BindableProperty]
public partial string Title { get; set; }

or

[BindableProperty]
private string _title;

The source generator creates the long declaration of the bindable property field:

public static BindableProperty <name>Property = BindableProperty.Create(...);

Since Roslyn source generators run independently of each other, our XAML SourceGenerator cannot see these generated bindable property static fields. This breaks apps which rely on this mechansim. For example:

<?xml version="1.0" encoding="utf-8" ?>
<ContentPage
    x:Class="BalancePage"
    xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
    xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
    xmlns:local="clr-namespace:App"
    x:DataType="local:BalancePage">

    <VerticalStackLayout>
        <Slider x:Name="BalanceSlider" />
        <local:BalanceView Balance="{Binding Source={x:Reference BalanceSlider}, x:DataType='Slider', Path=Value}" />
    </VerticalStackLayout>
</ContentPage>

namespace App;

public partial class BalanceView : Label
{
	[BindableProperty] public partial double Balance { get; set; } = 0.0;

	public BalanceView()
	{
            // ...
	}
}

This currently fails with the following error:

error MAUIX2002: No accessible property, BindableProperty, or event found for "Balance", or mismatching type between value and property.

I imagine we implement a heuristic which will detect that we are trying to assign a BindingExtension node to a property or a field which has "similar" name to the XAML property name ("Balance", "_balance", "balance") and the property or field has an attribute which is called "BindablePropertyAttribute".

I would start by creating a PoC with SourceGen.UnitTests coverage. Let's see if this is feasible or not before we commit to this feature.

Later, we might allow more different attribute names to meet the expectations of the community and we might allow more distance between the XAML property name and the property/field name.