.NETpad 2025: First Steps in Rebuilding .NETpad in WASDK/WinUI 3 (Premium)

I've made significant progress on WinUIpad, the Windows App SDK (WASDK)/WinUI 3 version of .NETpad. Here's a quick look at some of the challenges of this port, what I've done so far, and what's left.
Nothing is ever perfect
I've been working on a WASDK/WinUI 3 version of .NETpad for the past month or so. In .NETpad 2025: WinUI 3 is the Way Forward (Premium), I explained why, with a few examples of the many ways in which WASDK/WinUI 3 is superior to the Windows Presentation Foundation (WPF) for creating a truly modern Windows app. But that's only part of the story. There are other advantages beyond those I mentioned in that article. And there are negatives.

So many negatives.

And, no I'm not talking about the fact that Microsoft has pretty much ignored the Windows App SDK and the developers that use it for the past year or so, though that's certainly a discussion worth having. Granted, it's still better than the situation with WPF.

No, I'm speaking more of a "death by 1000 cuts" type problem with WASDK/WinUI 3.

To be fair to Microsoft, it has done a pretty good job over decades of giving developers who invested their time, energy, and codebases in .NET a way forward, at least at a high level. Even in the dark years of the Windows Runtime (WinRT) and Windows 8, when Microsoft abandoned .NET, the new framework was at least familiar, and you could still use C#. So that's nice. But the boots-on-the-ground reality is more nuanced. And the differences, big and small, between older and newer frameworks can be confusing, with many unexpected blockers. Everything is similar ... but also different. There are so many things to catch you up.

And I suspect this is a more pronounced issue for me than it might be for most. As I always try to stress, I'm not a professional developer. And I don't spend all day every day on this work. So it sometimes takes me a bit to get up to speed.

Anyway. Here's what I've been working on.
The basics
From a user interface perspective, .NETpad is not a complex app. There is a single main app window with four main areas from top to bottom: Tabs, menu, text box, and status bar. Then there are secondary interfaces in the form of dialog boxes and a settings interface.

I've mostly implemented these areas, which are controls, in XAML in the existing WPF version of .NETpad, though as I've pushed to figure out multiple documents and tabs, I've also experimented at great length with other ways of creating these UIs. Primarily in the form of dynamic C# code and via something called UserControl that segregates blocks of XAML code and its associated code-behind C# into separate objects (and files). Ultimately, I decided this was too much trouble, but I will continue forward with using dynamic C# code to create the contents of each tab.

And of course, I'm starting over with WinASDK/WinUI 3. At a high level, the basics are the same. I could use XAML to build out the user interface, as always. Or I could use...