Not for the PR.
We have huge places in our code base where we allocate such temp arrays. We could review this and use modern C# feature params ReadOnlySpan<YYY> to pass arguments in methods without allocation.

Question about the design. We don't keep property filter but only exclude filter. Is this really necessary? Looking how ApplyExcludePropertyFilter is inserted a question is - wouldn't it be more correct to apply the filter exactly at the time of adding new property in the list?

Yes, storing the filter is necessary to pass it from the cmdlet to ViewGenerator. Here's the class structure:

Format-Table cmdlet
    └── InnerFormatShapeCommand
            └── _viewManager: FormatViewManager
                    └── _viewGenerator: ViewGenerator (TableViewGenerator, etc.)
                            └── activeAssociationList (property list)

• ExcludeProperty parameter is defined in the cmdlet
• Property list is built in ViewGenerator.Initialize() using the input object (for wildcard expansion, DefaultPropertySet, etc.)
• ApplyExcludePropertyFilter() is defined in ViewGenerator (the base class of TableViewGenerator, ListViewGenerator, etc.)

Since the cmdlet and ViewGenerator are separate classes, we need a way to pass ExcludeProperty between them. ViewGenerator.Initialize() already receives FormattingCommandLineParameters, so adding excludePropertyFilter there was a natural way to pass it - same as -Property which is stored as mshParameterList in the same class.

Even with add-time filtering, we would still need to add a member to FormattingCommandLineParameters because that's the bridge between the cmdlet and ViewGenerator.

My main concern is that we call ApplyExcludePropertyFilter() 8 times. It is looks as not reliable, it is easy to make an error.
Also we have some places where we access activeAssociationList and this rises a question should it return already filtered list?

Thanks for the feedback. You're right - calling ApplyExcludePropertyFilter() at multiple exit points is error-prone.

I've refactored both methods to eliminate multiple return statements and call ApplyExcludePropertyFilter() exactly once at the end:

• Table Initialize(): 3 calls → 1 call
• Wide SetUpActiveProperty(): 4 calls → 1 call

Regarding activeAssociationList access: The existing design doesn't prevent access to activeAssociationList before Initialize(), but I've verified no such access exists. All external access (e.g., GeneratePayload(), GenerateHeaderInfo()) happens after Initialize() completes, so they always see the filtered list.

This is a good step forward. Thanks!
Nevertheless, can we think about making it more generic? Can it be in base.Initialize() for example? It would be great.

Thank you for the positive feedback and the suggestion!

I explored moving ApplyExcludePropertyFilter() into base.Initialize(), but found some structural challenges:

Current Structure:

Challenges with base.Initialize():

1. Timing: activeAssociationList is built by derived classes after base.Initialize() returns, so it would be null at that point
2. Wide's lazy initialization: Wide builds the list during GeneratePayload(), not during Initialize()
3. Complex doesn't use it: Uses a different rendering path

Possible approach - Template Method pattern:

// ViewGenerator (base)
internal virtual void Initialize(...) {
    InitializeHelper();
    BuildActiveAssociationList(so);  // virtual, overridden by derived classes
    ApplyExcludePropertyFilter();
}

However, this wouldn't work for Wide's lazy initialization pattern without additional refactoring.

Current approach:
Each Initialize method calls ApplyExcludePropertyFilter() once at the end, which handles all cases including Wide's lazy pattern.

Would you prefer me to explore the Template Method approach further, or is the current single-call-per-Initialize approach acceptable given these constraints?

Ideally it would be great to have clean class design. But if it requires a lot of refactoring, then it's better to postpone it, i.e. I can accept the PR as it is now, and you can do the refactoring in a subsequent PR if you want.

Thank you for the flexibility and understanding!

I agree that a cleaner centralized approach would require some additional refactoring. The current approach—calling ApplyExcludePropertyFilter() once at the end of each Initialize method—keeps the changes minimal and focused on the -ExcludeProperty feature.

I've opened #26568 to track the potential refactoring for the future. Please feel free to assign it to me if you'd like.

Feel free to grab the work. We are in beginning of next version dev cycle so we can do formatting and refactoring that way there's enough time to stabilize.

Thank you! I'll take on #26568.
Since the refactoring depends on the code introduced in this PR, I'll start working on it after this PR is merged.