Handed over to @costin-zaharia-sonarsource. The underlying PR describes the current status and the next steps.

Took it over from @csaba-sagi-sonarsource.
After discussing with @csaba-sagi-sonarsource and @costin-zaharia-sonarsource, I am going to:

• rebase onto the current master and fix conflicts
• extend unit tests to include missing Razor features (e.g. nested components)
• making sure everything works as expected and have a third round of review from @costin-zaharia-sonarsource
• if time allows, check locally the performance delta (overall build time on mud-blazor) w.r.t. master (before master validation on peach)

@costin-zaharia-sonarsource
I am doing backlog cleanup, and I have a question about this issue and its related PR.

The issue has been hanging on the Kanban board, for a while now.
At the time we decided not to proceed with razor tokenization, due to the issues with locations we had at the beginning.
In the end, however, if I recall correctly, we went for our own custom mapping logic, so this task may make more sense now.
There are still problems with location mapping in nested components, as explained in the description of the PR.
As mentioned here, #8040 should be addressed first.

There is quite a lot of code, and the PR went also for a round of review.
However, the branch has become stale, and by now there are 10 conflicts with master.

How would you advise to proceed?

Since there are still problems with the mapping and the Roslyn APIs don't help us much currently, I would prefer to pause this effort for now. In my opinion, we should wait for the compiler team to finish the current effort in improving the API and continue when the new registrations are available.