## Summary

On Android, an intermittent **`System.ArgumentOutOfRangeException`** crashes the app
(unhandled) during heavy UI re-layout of a page that contains Telerik `RadEntry` and
`RadButton` controls. The exception originates inside Telerik's `RadBorder` re-parenting a
`SolidColorBrush` (`RadBorder.OnBorderBrushPropertyChanging/Changed` → MAUI
`Element.SetParent` → `RemoveResourcesChangedListener`). It is consistently preceded by a
fixed sequence of framework warnings (below). It reproduces on multiple devices and is
timing/memory dependent (more frequent on lower-RAM hardware).

## Environment

- Telerik UI for .NET MAUI: **10.0.0**
- .NET MAUI (Microsoft.Maui.Controls): **9.0.90**
- .NET runtime: **9.0.16**
- Target: `net9.0-android35.0`, min Android API 26; Build configuration: **Release**
- Observed on, among others: Samsung **SM-A156E** (Android 16), **itel P10004L** (Android 14)
- Also reproduces as a **handled** (non-fatal) exception on page teardown — same stack.

## Exception & stack trace

`System.ArgumentOutOfRangeException: ArgumentOutOfRange_IndexMustBeLess Arg_ParamName_Name, index`

```
System.Collections.Generic.List<Action<object, ResourcesChangedEventArgs>>.RemoveAt(int)
System.Collections.Generic.List<Action<object, ResourcesChangedEventArgs>>.Remove(Action<...>)
Microsoft.Maui.Controls.Element.Microsoft.Maui.Controls.IElementDefinition.RemoveResourcesChangedListener(...)   Element.cs:447
Microsoft.Maui.Controls.Element.SetParent(Element value)                                                          Element.cs:405
Microsoft.Maui.Controls.Element.set_Parent(Element value)                                                         Element.cs:384
Telerik.Maui.Controls.RadBorder.OnBorderBrushPropertyChanging(object oldValue)         (In app — Telerik)
static RadBorder()+(BindableObject b, object o, object n) => { }                         (In app — Telerik)
Microsoft.Maui.Controls.BindableObject.SetValueActual(...)                               BindableObject.cs:640
... (style/binding apply) ...
Microsoft.Maui.Controls.Setter.Apply / Style.ApplyCore / MergedStyle.SetStyle
Telerik.Maui.Controls.RadButtonBase.set_ActualStyle(Style value)                        (In app — Telerik)
Telerik.Maui.Controls.RadButtonBase.UpdateActualStyle(...)
Telerik.Maui.Controls.RadButtonBase.OnStyleChanged(...)                                  (In app — Telerik)
... BindingExpression.Apply → Dispatcher.DispatchImplementation → RunnableImplementor.Run
```

(The same stack appears both as an **unhandled** crash and, on page teardown, as a **handled**
exception.)

## Framework warnings that ALWAYS precede the crash (in order)

```
BindingDiagnostics: 'BorderColor' property not found on 'Telerik.Maui.Controls.RadEntry',
                    target property: 'Telerik.Maui.Controls.RadBorder.BorderColor'

Element (warning): The RealParent on Microsoft.Maui.Controls.SolidColorBrush has been
                   Garbage Collected. This should never happen. Please log a bug:
                   https://github.com/dotnet/maui

Element (warning): Microsoft.Maui.Controls.SolidColorBrush is already a child of
                   Telerik.Maui.Controls.RadEffectsView. Remove ... before adding ...   (x many)
Element (warning): Microsoft.Maui.Controls.SolidColorBrush is already a child of
                   Telerik.Maui.Controls.RadBorder. Remove ... before adding ...
```

## Reproduction

1. A `ContentPage` inside a `NavigationPage` containing several Telerik `RadEntry` and
   `RadButton` controls, styled via **implicit styles** that set `BorderBrush` across multiple
   `VisualState`s (Normal/Focused/Invalid/ReadOnly/…). No custom `ControlTemplate` is applied;
   only `BorderBrush` (and background/text) setters.
2. Interact with the page, then trigger a re-layout one of two ways:
   - **Resume:** background the app (e.g. launch another app), then return →
     `Window.Resumed`/`Activated` re-applies styles. → tends to be the **unhandled** crash.
   - **Teardown:** navigate away from / destroy the page (`Window.Destroying`). → tends to be
     the **handled** exception.
3. Intermittently (timing/memory dependent; more often on lower-RAM devices) the warning burst
   above appears, immediately followed by the exception.

## Our analysis (why we believe this is in the Telerik template)

- The throw originates from `RadBorder.OnBorderBrushPropertyChanging/Changed` re-parenting a
  `SolidColorBrush` (`Element.SetParent` → `RemoveResourcesChangedListener`).
- The preceding **`'BorderColor' not found on RadEntry → RadBorder.BorderColor`** binding is
  *internal to the RadEntry control template* — `RadEntry` exposes `BorderBrush`, not
  `BorderColor`, and we do not define a custom RadEntry template; we only set `BorderBrush` via
  styles.
- The repeated **"SolidColorBrush is already a child of RadEffectsView / RadBorder"** indicates
  the same brush instance is being re-parented within the Telerik visual tree on every style
  re-apply, which trips the underlying MAUI weak-reference defect ("RealParent … Garbage
  Collected") and corrupts the resource-changed-listener list.

## What we have ruled out

- **Not forced GC** — our only `GC.Collect()` calls are `#if DEBUG`; production has none. The
  GC clearing the brush's RealParent is the *natural* GC.
- **Not the Windows/SkiaSharp/RadDataGrid variant** of the "already a child" warning — this is
  Android and no `RadDataGrid` is involved.
- **Not app-side brush sharing** — our border color resources are `<Color>` (not shared
  `SolidColorBrush` instances), and we set `BorderBrush`, not a custom `RadBorder`/template.

## Questions

1. Is the RadEntry template's internal `RadBorder.BorderColor` binding to a (non-existent)
   `RadEntry.BorderColor` a known issue? Should it target `BorderBrush`?
2. Why does the RadEntry/RadButton template re-parent the *same* `SolidColorBrush` across
   `RadEffectsView`/`RadBorder` on each style/visual-state apply (the "already a child"
   warnings)? Can the template avoid re-parenting shared brushes?
3. Is there a Telerik UI for .NET MAUI 10.x release that addresses RadBorder/RadEntry brush
   re-parenting on style re-apply / the listed warnings?
4. Recommended mitigation for `RadEntry`/`RadButton` styling to minimize this re-parent churn
   (e.g. preferred way to set border brush per visual state)?

## Related public reports (MAUI side)

- dotnet/maui #25739, #23050, #28608 — "The RealParent on … has been Garbage Collected" — same
  underlying weak-reference defect; mostly closed without a fix, hence reporting via Telerik as
  the template owner.