The Children property is declared as IReadOnlyCollection<ITreeItemData<T>>? with a setter, which creates an API design issue. IReadOnlyCollection<T> indicates immutability of the collection, but having a setter allows replacing the entire collection reference. This is semantically inconsistent - the interface name suggests read-only behavior, but the setter allows mutation at the reference level.

Consider one of these alternatives:

1. Use ICollection<ITreeItemData<T>>? if the collection is meant to be mutable
2. Make Children a get-only property if it should truly be read-only
3. Use IEnumerable<ITreeItemData<T>>? if you only need enumeration with settability

The setter is necessary for Blazor’s @bind-Items="context.Children".
This is an intentional design choice. We don’t want the list to be modified using Add, because in that case we wouldn’t know the list has changed, and the DOM wouldn’t update automatically. The end user would have to trigger the update manually, which isn’t very friendly. We would need to introduce some sort of observable list, subscribe to change and call StateHasChanged, which we don’t want to do.

The idea is that if you modify Children, you create an entirely new list.

This exactly why Add doesn't work well with Blazor #12079 (comment) which is why it's always best to push item as new collection, and IReadOnlyCollection helps to avoid it. Not end user can modify the list and wonder why something doesn't work or why it behaves strangely.

The same API design issue exists in the implementation. The Children property is declared as IReadOnlyCollection<ITreeItemData<T>>? with a setter, which creates semantic inconsistency. While the property can be set to a new collection, the IReadOnlyCollection interface suggests the collection itself should not be modifiable, creating confusion for API consumers.

This is particularly problematic because code like item.Children.Add(...) won't compile, forcing users to replace the entire collection even for simple additions, which is inefficient and awkward.

Same comment like above with IReadOnlyCollection<ITreeItemData<T>>? Children { get; set; }

This code demonstrates the awkwardness created by using IReadOnlyCollection for the Children property. To add a child item, you must:

1. Convert Children to a mutable list with .ToList()
2. Add the new item to the list
3. Reassign the entire collection back to Children

This pattern is inefficient and awkward. If Children were declared as ICollection<ITreeItemData<T>>? or List<ITreeItemData<T>>? instead, you could simply call primaryItem.Children.Add(...) directly, which would be more intuitive and performant.

While this doesn't looks as friendly, it's quite common pattern when working with immutable list.
It doesn't mean the list will never modify and be in a "locked" state, the items might be added through creating new collection and supplying it, we just don't want the descender API to modify the collection unexpectedly.