Some isnpiration from the Roslyn implementation:

> dotnet new console
> dotnet build /p:ReportAnalyzer=true /bl
> .\msbuild.binlog

We do not have to necessarily be same level of detail or structuring in binlog in the V1, though.

We can just flush the stats as a single message or a series of messages, and then have a separate workitem for making those better organized in the Binlog Viewer (similarly as the Roslyn stats have a special case presentation logic: https://github.com/KirillOsenkov/MSBuildStructuredLog/blob/4116c37b386613684c270893f2d0a606f82b465d/src/StructuredLogger/Analyzers/CscTaskAnalyzer.cs#L9)

Consider the use of System.Diagnostics.Activity here instead of Tracing directly - a lot of the runtime/tooling have embraced Activities as a more convenient and user-accessible way of tracking not only the duration of a unit of work, but also metadata for that unit of work that might be useful (a la structured logging!) and the parent/child relationships of that unit of work to other units of work. This level of instrumentation is pretty common in our (MS) application frameworks and libraries now. We've got some conceptual docs for it here, and I'm happy to talk more about it - we're making pretty big bets on it BCL-wide.