Unfortunately, none of these are responsible for the startup delay. Since version 1.18 effectively ~90% of the startup duration is spent starting up WinUI and having it draw the tab bar and window frame. It still needs a second to start. If it still used GDI like Windows NT did, it would start in well under 100ms even on an extremely old CPU.
Fixing this situation is essentially impossible because it requires rewriting almost everything that modern Windows is built on. Someone else in this thread said you couldn't sell 4 quarters worth of work to fix this, but the reality is that it requires infinite quarters, because it requires throwing away the last 10 years of Windows shell and UI work and that will never happen. You could paper over it by applying performance spotfixes here and there, but it'll never go back to how it could be that way. At a minimum, you'd essentially have to throw away WinRT which has an almost viral negative impact on performance. Never before have high latency, but still synchronous cross process RPCs been that prevalent and everything's a heap allocated object, even if it's within the same binary. It's JuniorFootgunRT.
Yeah, you're right, they're related to WinUI. But what I meant is that such features aren't inherently expensive, they're just made expensive due to the choice of UI framework.
Display scaling is very fast in GDI apps and has no impact on launch time, a tab bar is essentially just an array of buttons (minimal impact on launch time?) and transparency is a virtually cost-free feature coming from DWM. I wrote a WinUI lookalike using its underlying technology (Direct2D and DirectComposition) directly one time and that results in an application that starts up within ~10ms of CPU time on my laptop, quite unlike the 450ms I'm seeing for WinUI. That is including UIA, localization and auto-layout support.
I do keep my config backed up and synced between my computers. It doesn't change that much but it's nice having it easily synced across my many machines when I do make a change.
And no, copying text hasn't been Ctrl+c. That sequence sends a sigint to the process, not a copy request. To copy text by default cmd made you enter a mark mode which then had you essentially draw a rectangle and it would then copy as newline characters even when it should have just continued the line. The old copying process of cmd is terrible.
Tabbed interface
Support for command interpreters other than just CMD
Multiple profiles for different interpreters and settings
Support for a much wider range of console control characters and terminal emulations (ssh'ing into linux boxes works really well)
Way better resizing support
Clickable URL detection
More (and customizable) keyboard shortcuts
Support for background images
Support for transparency
Configurations as easy to transfer JSON files
Copying text is a way better experience
Just a few of the features that I use all the time. I can't stand using cmd.exe anymore, its an absolutely miserable experience in comparison.