SourceGen: VisualStateManager.VisualStateGroups causes 'Names must be unique' at startup

[StephaneDelcroix]

Description

When using VisualStateManager.VisualStateGroups in XAML with the source generator, the app throws InvalidOperationException: VisualStateGroup Names must be unique at first startup.

Expected Behavior

The page should load without errors — each VisualStateGroup name appears only once in the XAML.

Actual Behavior

System.InvalidOperationException: VisualStateGroup Names must be unique
   at Microsoft.Maui.Controls.VisualStateManager.Validate(...)

Steps to Reproduce

1. Create a page with a Button that has VisualStateManager.VisualStateGroups:

<Button Text="Press me">
    <VisualStateManager.VisualStateGroups>
        <VisualStateGroup Name="CommonStates">
            <VisualState Name="Normal">
                <VisualState.Setters>
                    <Setter Property="BackgroundColor" Value="White" />
                </VisualState.Setters>
            </VisualState>
            <VisualState Name="Pressed">
                <VisualState.Setters>
                    <Setter Property="BackgroundColor" Value="LightGray" />
                </VisualState.Setters>
            </VisualState>
        </VisualStateGroup>
    </VisualStateManager.VisualStateGroups>
</Button>

2. Build and run — crashes at startup

Root Cause

The SG-generated InitializeComponent processes the VisualStateManager.VisualStateGroups collection-type attached property. During processing, the VisualStateGroupList validation callback fires and finds a duplicate "CommonStates" name — likely because the group is added to the collection during construction and then the list is assigned to the property, triggering re-validation against a pre-existing entry.

Affected Area

• XAML Source Generator (SourceGen)
• SetPropertiesVisitor handling of collection-type attached properties with named items

[StephaneDelcroix]

This was caused by the InitializeComponentRuntime fallback (diagnostics/HR) re-processing the page and double-adding the VisualStateGroups. Fixed by suppressing the ICRuntime fallback when XIHR is enabled (commit f98f3eecd3 on feature/xaml-incremental-hotreload).

The XAML unit tests from PR #34719 all pass — the SourceGen codegen itself is correct. The issue was specific to the XIHR branch's interaction with the diagnostics fallback path.

[StephaneDelcroix]

Reopening with correct root cause:

The bug is NOT in the ICRuntime fallback. It's in SetPropertiesVisitor (line ~275-291): for attached collection properties like VisualStateManager.VisualStateGroups, the SG calls GetValue() to get the existing collection and then Add().

When the element has an implicit style (e.g., default Style TargetType="Button" in Styles.xaml) that already sets VisualStateGroups with "CommonStates", the GetValue() returns the style's list that already contains "CommonStates". The SG then Add()s another "CommonStates" group → duplicate → crash.

This is a vanilla SourceGen bug, reproducible on any branch. The default template Styles.xaml includes Button styles with VisualStateManager.VisualStateGroups, so any Button with explicit VSM in XAML will crash.

The fix should either:

1. SetValue with a fresh list instead of Add() to the existing one, or
2. Clear the existing list before adding