.NETpad 2025: Return to Sender (Premium)

I'm at a weird point with the next version of .NETpad. The basic coding for multiple tabs and documents is mostly complete, albeit roughly. I'm still stepping through each of the event handlers and helper methods that interact with tabs and the documents they contain to make sure everything works correctly. And in doing so, I keep finding ways to improve the code quality. It feels like I'm in some kind of holding pattern.
Tied to this, I'm considering doing things a bit differently with the 2025 version of .NETpad. That is, rather than wait until this version of the app is "done" to post it to GitHub, as I did with last year's version, I will likely publish this version as I work on it, perhaps after whatever major milestones. So the version I have now, for example, might be a good candidate, at least once I "finish" my code quality pass.
The problem is, I can't stop screwing with it.
As I noted in the previous progress update, I have been further modularizing the code with the vague aim of minimizing the code in event handlers (which are all found in MainWindow.xaml.cs) and expanding my use of helper methods and, in doing so, reducing code duplication. In doing this work, I kept running into a familiar pattern in which most of the helper methods I had created--Save(), SaveAs(), NewDocument(), OpenDocument(), and so on--could be improved by changing them to return a value of some kind, usually a bool (Boolean, which can be true or false), instead of a not doing so (using a void return type). This allows me to determine whether whatever that method does was successful, which is obviously useful.
As I also noted in that previous progress update, I've been making tentative first steps into using AI to help me improve my code quality. As is the case with all my work, I don't use AI enough, and I'm not using it as effectively as I could. But the inadvertent full-project code assessment I made with the Cursor AI editor was particularly interesting to me. It confirmed some of the work I had already done--including the increased modularization--but it also suggested I could do more.
So let's start there.

More modularization, more code improvements
Yesterday, I took the advice I got from Cursor (really, from Anthropic Claude) to heart and created two more source code files that now contain topic-specific code: AppSettings.cs for all application settings-related code (right now, just two huge helper methods, LoadSettings() and SaveSettings()) and FileOperations.cs for all the file-related helper methods (Save(), SaveAs(), NewDocument(), etc.). This lightened up Backend.cs considerably--this file now contains helper methods related to text handling, confirmation dialogs, find and replace, and a few other random things--so I guess there is a readability gain here. I also worry about their being "too many" of these files, in that I often stare at Visual Studio, wondering where I can find my own source code. But, OK.
One specific recommendation...