We could merge both methods if they are always used together.

They are not used together. OnSuggestionDisplayed will be fired way more than OnSuggestionAccepted.

My thoughts are if we get 100 suggestions we could weight all 100 (including displayed and accepted ones) and return the result to the prediction service so that it could make more better analyze. So users could prefer a case-sensitive selection or use other sources for selection (local configs, history or other prediction services) to inform the prediction service.

My thoughts are if we get 100 suggestions we could weight all 100 (including displayed and accepted ones) and return the result to the prediction service so that it could make more better analyze.

It's pretty common that we get suggestions from a predictor but user doesn't accept anything, so it's not clear to me how to always include "displayed and accepted ones" in a feedback.

After this change, "OnSuggestionDisplayed" event will be fired very often. I very much want to reduce it ..., so any ideas are very welcome. Can you maybe elaborate your thoughts more?

So users could prefer a case-sensitive selection or use other sources for selection (local configs, history or other prediction services) to inform the prediction service.

Not sure I understand what you mean, it would be nice if you can clarify more. Basically, we try to avoid sending more user local infor to a predictor than really needed.

We've heard more than once that users want to restore a PowerShell session after a restart. For this service it might be useful too.

My thoughts may be vague, but I believe that if a service does not store permanently the (session) state, then this state should be stored locally.

What is a session data? (1) Personal sensitive user data (stored only locally), (2) service data. Service data may be (1) complex data structure (like subset of ML model), (2) simple tips (references on internal service models)

I think that if user data should not be stored on the service, then there might be the following options:

1. No data is stored locally between sessions
2. All session data is stored locally (including model)
3. All sensitive data is stored locally (including service tips).

Also I think there are many claims about sensing user data to Cloud. The service could be data agnostic and gets encrypted data.

This feels like a design proposal for a separate feature "restore a PowerShell session after a restart" :)

Why uint? Maybe Guid to be globally independent?

The session is always under a context, for example, a period of time when a predictor module is loaded and used, a Runspace instance id where the module is loaded. That context can be uniquely identified, so I think there is no need for the mini-session to be globally unique.

I use uint only because it provides a large space and easy to increment to get a new mini-session id. Azure PowerShell team is using this prediction API for the Az Predictor. I'm waiting on the their feedback on this.

The Az.Predictor team has confirmed that uint works fine, becuase they already have other context information that is uniquely identifiable. /cc kceiw

Perhaps use [CallerArgumentExpression("value")] ?

It's not implemented yet, right? See the proposal doc and the open issue: dotnet/csharplang#287

You're correct! I was misled by the docs. I have used CallerMemberName and read the documentation for CAE and just assumed it worked as well.

... make NuGet packages include the XML document files.
This is not really related to prediction APIs. Could have been a separate PR.

Not directly related, but sort of. The script needs to be updated after the changes in API because new attributes are used which need to be scrubbed when generating the reference assembly, so I have to update the packaging scripts. While doing so, I found the XML docs are missing when using our NuGet packages in VS Code or Visual Studio, and thus I fix that too.
Since we need to include part of the fixes in packaging.psm1 anyways, I prefer to keep all changes in this PR.

Can you please explain why this is needed?

The CompilerGeneratedAttribute and IsReadOnlyAttribute are added by the C# compiler to the readonly members of a struct in the generated IL. Those attributes can only be used by the C# compiler and thus will result in complication error when they are in the source code. Therefore, we need to scrub them out before compiling to get our reference assembly.