Currently, OnEntry etc are all void methods, meaning they're not inherently async friendly. It's becoming exceedingly rare to be able to write code without calling async methods these days, and it's more and more common to need to call async methods from within an OnMethodBoundary aspect (database or web service calls especially).

The naïve approach of simply changing the override signature to make the aspect async void in order to be able to await within the aspect has subtle issues which are not intuitive to debug.

Ideally, we'd have additional overrides available in OnMethodBoundaryAspect for Task OnEntryAsync and Task OnExitAsync so that we can await inside these aspects without risking unexpected behaviour.

I understand that at the IL level these are actually two separate types of injection, but I have on several occasions wished I could add a module initializer to an assembly from an aspect provider, not by marking an existing static member as one but by including the module initialization behavior in the aspect itself. Similarly, there are a few types which could have benefited from automatic introduction of static members (perhaps a new StaticTypeLevelAspect base class?). I imagine these are similar in some manner of abstract implementation detail, yet wind up being somewhat unrelated due to the way module initializers are implemented under the hood, but to me they have been related in their usefulness.

Allow usage of External target attributes to be used in conjunction with aspects applied to types or methods, rather than just assembly-wide introduction.

It would also be especially helpful to be able to use something similar to aspect providers to choose which external methods to advise with which advice, sharing aspect instances as desired rather than applying a single universal aspect instance to all sites. It seems like this might be better suited for a new interface, but the important feature would be to allow the provider logic to decide which advices to apply based on the context of the method/type that it is being called from.

We often want to do something when a certain property value changes. Therefore, it will be very convenient if in the case of a value change, the PostSharp library will run a predefined function.

For example, in ViewModel there is a property named ProductId.

The programmer will be able to write a function called OnProductIdChanged that will be executed if the ProductId value changes.

How it will happen: When the value of a property changes, the PostSharp library checks whether there is a function named OnPropertyNameChanged. If it does, it will be executed.

This need is so common, and saves the need to subscribe to the PropertyChanged event at ViewModel.

Here is page https://www.postsharp.net/alternatives.

Here is column header
```
Niche Languages
F#, Erlang
```

I doubt Erlang relates to .NET as viable alternative at at all.
Niche Language which is Niche and is concurrent of Postsharp is https://github.com/rsdn/nemerle.

What `niche language` means?
F# may be `niche` as current number of users.
But F# is NOT Niche about its applicability. Its applicable in areas of scripting and tooling and data munging and secured engineering is LARGER than of C#. In this sense C# is `niche`.

About F#. Your statements are wrong and do you bad job advertising Postsharp product management of being unaware of alternative and telling falsehoods.

`Empowers every team member: architects, senior developers and application developers`. Operations, support, analysts, build engineers are not part of team?
F# empowers all parties you forgot to mention. More, F# empowers people because it is free.

`Makes source code semantically simpler and more concise`. Just Google it. F# does it much better then any amount of tooled C#.

`Improves architecture and makes application maintenance easier and less expensive `. Again F# does this and Google it.

No checked other statements lower in table, but there should be critique either.

If you do not want to look bad, drop Erlang. Change `niche` with specific language columns like `F# Language` `Nemerle language`